Coding Blocks - Caching in the Application Framework

Episode Date: August 27, 2016

Storing smaller subsets of data in a faster, closer memory can make astronomical differences in performance. This episode we’re talking about the caching tools and techniques that application frameworks provide. The original version of the shownotes can be found at: http://www.codingblocks.net/episode46 New Poll! Podcast News Thanks for the reviews! Mr_Automation, Nateve, chubb5000, Travelerbell, LaCaren, ryanwebjackson, […]

You're listening to Coding Blocks, episode 46. Subscribe to us and leave us a review in iTunes, Stitcher, and more using your favorite podcast app. Visit us at codingblocks.net where you can find show notes, examples, discussion, and more. Send your feedback, questions, and rants to comments at codingblocks.net and follow us on Twitter at Coding Blocks or head to www.codingblocks.net and find all our social links there at the top of the page. With that, I'm Alan Underwood, the not southern sounding guy. Wait.

Wow, that's not going to get confusing. I'm Egon. My name is Joe Zach. I got distracted. You guys see me off. Yeah, I'm Joe Zach. No, you're Egon. And hi, y'all.

I'm Michael Outlaw. There it is. All right. Now, nobody will be confused from here on out. No, I'm pretty sure that we totally threw everyone off. So with that, welcome to Coding Blocks. So for those not in the know, what happened was... We should just start over.

No, we're good. I was still filling in notes. Reddit was good to us. One piece of comment that came back from it, though, is that several people commented that they had a hard time differentiating our voices because we all sound the same. One guy described us as Alan talks southern, Michael talks fast, and Joe sounds like Egon. That was an amazing post.

That made me so happy. Yeah. You actually liked that one and replied. Oh, yeah. I'm a Redditor. So from now on, I'll just do the show introductions as like, hi, y'all. This is Coding Blocks. Hey, we need to give some credit for whoever whoever

put that in there right because it was uh oh i don't remember who that specific comment was that you know i was talking about how we sound but uh this all started from a uh a reddit about you know my top eight must listen developer podcasts and uh the lesser nut responded back because uh coding blocks was not listed and uh at least when i looked at it we were the you know part of the top comment uh alan seems to have seen some different results yeah the the top comment was nobody has time to listen to i guess some programming so but it was pretty cool to see us pop up in there because we definitely don't go and seed those things. So that was amazing.

Yeah, that was totally awesome. It's really cool to see something that you did on Reddit and not get beaten down into the ground. Oh, totally, man. That's usually what happens. It's a pound fest. You get killed on those things. Sometimes the internet just can be so cruel

yeah so that but this time it wasn't that was a smile yeah that was a smile for all of you got to take your small victories where you get them so with continuing with the smiles we got a few more reviews in itunes and stitcher i feel like i should go ahead and use this good karma to read these names because i think i can say these no man this one's too easy that's not fair no come on hold on dude we don't even have any hard ones this time so yeah so so no these are totally hard uh itunes is uh how do you say this mr automation uh nat eve Chubb5000, because the other 4,999 are already taken, Traveler Bell, and LaKarin. And then in Stitcher, we got some love there from Ryan Webb Jackson and Lucky Coding.

Yep. Thank you very much for all those. They truly made our days. And, yeah, I mean, just amazing stuff. So appreciate that. Keep them coming. You know, if you find five minutes and you're bored out of your mind, there's a good time to go sit down and write a review for Coding Blocks.

Hey, and you know what? Just take a lesson out of the Lesser Nuts playbook, and if you see something mentioned on Reddit where you think that we would be a good fit, hey, you know, we won't mind. It won't hurt our feelings. Throw us in there. We love it. Love it.

Thank you. Says Egon. And speaking of love, SwanseaCon is coming up. It's a conference that we talked about last year. It focuses on refactoring, code spells, agile coding practices. Just some really great talks. And it's coming up. It's in South Wales, which is very far from me, unfortunately,

because I really want to go. But it's September 12th through 13th in South Wales. And I just wanted to read a couple of my favorite talk titles in there, talks like Refactoring Code Smells, 10x Delivered Myth, and my favorite, From Jurassic Park to Microservices. That's an amazing title. Yeah, I've worked with some dinosaur code bases so that uh that one felt good and we have some really good news this year we have a couple tickets to give away what so yeah if you think you're going to be able to make

it to south wales which uh i know is a little difficult for some people but if you think you can make it to south wales sept September 12th through the 13th, then I want you to tweet at Coding Blocks with the hashtag SwancyCon. And that's S-W-A-N-S-E-A-Con. So tweet to us with the hashtag SwancyCon and we'll enter you into the contest and you could potentially win a ticket

which is worth uh you know up to uh 450 pounds or you know for us uh americans uh around 600 bucks and don't hey don't be upset if i somehow win the drawing well do us a favor though like only bother to tweet if you're truly interested in going because that's a commitment to go to the south wells yeah and i tweet if you're truly interested in going because that's a commitment to go to the South Wells. Yeah, and I mean, if you're in the UK, which several of our listeners are, this is an excellent opportunity. Yeah, so definitely tweet us.

It looks like it's going to be an amazing conference, and again, don't be upset if I accidentally win this somehow. All right. I feel like we won't be seeing Alan much in September. Unfortunately, the flight is not included, so I won't be there this year. But hopefully if I talk real good about him, maybe next year. Maybe. Yeah, this is just the tickets to the conference, period.

Yeah. Year on your own for room and board and travel and all that. Yep. All right. So what do we got next? We had some fantastic comments on our last show. We got a lot of feedback about it, as usual. And in particular, there were three comments on the actual link for that,

rather the show notes for it, if you go to www.cuttingblocks.net slash episode 45, I wanted to call out three in particular. Russell Hammett had a great video of Grace Hopper discussing and visualizing nanoseconds, which was a hard thing for me to pronounce, let alone visualize. So that's a great video.

Carol Ann always granting us some great perspective, mentioning, talking about our poll and how sometimes discrimination can kind of masquerade as other things and a great tie-in with imposter syndrome there. Jerry Shannon had a fantastic presentation he linked to for the title. The presentation was Low-Level Details

for High-Level Developers, which has already piqued my interest. So you guys should go check that out in the comment section. Awesome. I had a link here. I really wish we had mentioned this last time. I thought about it and somehow didn't make it into the notes.

But there is a funny news story that kind of made the rounds, I don't know, maybe a year or two ago, about Amazon wanting to ship your package before you actually order it. And I thought this was a great example of some of the caching things that we talked about last episode and tie into temporal locality. Of course, Amazon isn't actually going to ship a package to you before you order it. But what they would do is ship packages that they think people in your area are more likely to buy to a warehouse closer to you. So if you live in, say, Boston, then they might start shipping popular coats and snowshoes to a warehouse near near you in the

winter months and if you live in florida like i do they might start uh sending things like bathing suits uh to my local warehouse in december that's pretty cool so yeah we'll have a link to that it's just a cool little story about what they're doing there unfortunately Unfortunately, it's patented, so don't think about doing this. You will get sued into the ground. So, kind of tying into our topic last week, or not last week, but last episode, and we went through all the

different levels of caching and specifically talked about memory and access speed to it. Have you guys heard about this new breakthrough that Intel and Micron made? No. Called 3DX Point. And it's a new non-volatile memory.

And SecurityNow did a great explanation of it. So we'll have links to everything in there because it's way better than anything. I need to go back and listen to it again just to be able to comprehend it. But yeah, it's this new technology that Intel and Micron have come out with a thousand times faster than NAND,

a thousand times the endurance of NAND, and 10 times denser than conventional memory. That's amazing. NAND, like is it not and? Okay, sure. We'll go with that. that's amazing NAND like is it not AND um okay sure we'll go with that it's basically the technology that all SSDs have been using for a while right

yeah I don't know if that's true or not but I took a class a long time ago we talked about like logical gates ANDs or NANDs XORs all sorts of stuff I don't know if that's a tie in there I don't know enough about it I've never actually seen one of those gates in real life or talked about it in the workplace. So I keep hoping to use some of this knowledge

that I picked up back at school. Yeah. I mean, this stuff just sounds amazing. And supposedly this is not just theory talk either. Like this is stuff that's going to be hitting the real world um i think they said by the end of the year by like sometime within 2016 it was supposed to be coming out now i don't know if this is going to be like that 60 gig terabyte or i'm sorry 60 gig terabyte why don't just make some stuff up 100 meg terabyte yeah you know sounds amazing i'll take two of those uh the 60 terabyte ssd that was only

for um you know commercial use or you know expected to only be used for commercial use because it was going to be ultra expensive so who knows you know this thing might start off start out its life that way but uh it still sounded very interesting and and um i just found it kind of timely considering the last episode and the conversation we had there that'll be our next level of cash right that's amazing um yeah i mean well i don't know about using it for cash necessarily just memory what but you know whatever very cool yeah it was pretty awesome all right so next up, Outlaw and I actually visited a React.js plus Elixir plus RethinkDB meetup that was pretty interesting.

It was talking about creating real-time reactive apps. And Elixir in the middle was basically for the nine nines of uptime type reliability. And RethinkDB was kind of interesting because it was a database that had, it was almost like event streaming to where when you update the database, it sends out events that people can subscribe to. It was almost like a stack or a queue built into a database.

So that was kind of interesting. The cool part about the meetup and the part that went completely over my head was when they were flashing through the examples of the code on screen. Like I didn't understand any of it. Oh yeah. Cause, cause elixir.

Let's see if I have this right now. Cause it was elixir and Phoenix. So Phoenix was built on top of elixir and elixir is built on top of Haskell, right? Uh, Erling. No. Yeah.

You're right. Erling. Yeah. Erling. Um, and that's where right, Erling. Yeah. Erling. And that's where the five nines came in, a reliability because it was based on Erling. And if you've never done any Erling before, then you look at that stuff and you're like,

hey man, you got a typo there. Like 20 of them. You're missing some stuff. Where are your braces at? Everything just looked wrong, and yet it works amazingly well. And it started off, the conversation started off, too, with this whole conversation about functional programming. And that's part of the way that Erlang is able to make its claim

about its reliability because this thing started out, um, with something that Sony Ericsson had, uh, you know, started out for, you know, they needed it for telecommunication purposes and because it was for telecommunication purposes and had to be relied upon, then it had to have, uh, you know, ultra high reliability. And, um, you know and they had servers that ran for decades using this thing. So yeah,

Elixir was built on top of that. And then this was a React meetup, but it kind of really wasn't a React meetup. It was more like this other cool stuff. So yeah, React and Redux were there at the presentation layer but really

you know what stole the show was elixir and phoenix and then rethink db which if you've never looked at rethink db um to me i don't know if you this is your takeaway it was almost like hey what if your database provided a pub sub model that's exactly that's what i'm saying it was like a queue on top of a database yeah i mean it was like well yeah see that's where like i mean maybe you could call it a queue but like i like when people say when you think of pub sub it definitely kind of sound like because you could say like hey i want to subscribe to this table yep and just tell me anytime there's a change to it or i want to subscribe to this query that's what it was and tell me tell me if new results for this query

ever come back so you never had to query your database for information the database would just tell you like oh well here's the here's the new value or the new row for that query result. And it would just publish it out to everyone who needed to know. It was pretty interesting stuff, and I'd never really heard of RethinkDB, so it was neat to see how that was done. I don't think it's something you plug into your existing architecture, but, I mean, it's just kind of nice seeing all this stuff that's out there. The one topic that we won't go into here, but I thought was really interesting that

he brought up is he, he said, um, think composition over inheritance and don't share anything. And I was like, whoa, whoa, whoa, whoa, whoa. Wait a second. I'm an object oriented guy. Like I've been doing OO for a long time. What do you mean? Don't share anything and don't think inheritance. And it, you know, I ended up going and looking the stuff up and maybe we'll do a part of

another episode on this, but you know, maybe if you want to do some Googling just to get some background information, it is a pretty neat concept and one that, that makes a lot of sense. And there's a wiki article that I'll, I'll, article that I'll link to in the show notes here. Yeah, I was sitting next to Alan, and I had to hold him back because he wanted to jump out of the seat when the guy was like, don't share. I was like, my mama said, don't share.

So let's do this. Of course, the southern guide is mama. Mama's always right. Mama's always right. Isn't it Billy? I can't remember. Billy Madison? No, no. You're thinking of Waterboy.

Alligators got nobody to clean their teeth. That's why they're always angry. No, they're so ornery. They're so ornery. Because they got so many teeth. It's a brush. Why are you just messing up this quote all together? So there are a lot of benefits to functional programming.

We should really talk about one of these days. But I really got to wonder how many people are doing how much true functional programming in the workplace. It seems if you're doing kind of line of business, like normal day-to-day stuff, I just don't really see that stuff too often. But I understand the benefits of having no shared know having no shared data you know you can split stuff off um really easily you can um you can cache stuff it's much easier to test which is easy to work with well that's what i was about

to say just think about like anytime anytime you've ever written any type of method that even quasi acted functional right like you weren't might not have even been trying to write you know any kind of functional code but you know maybe it just lucked out to be that way. Those are always the easiest pieces of code to go back and write unit tests for, always. Yeah, an input and a guaranteed output, right? There's no state mutation. I mean, that is my favorite kind of code to write right there. I will say, though, I've been looking at some, I hate this term, big data things here lately.

But Apache Spark, like one of the languages that is sort of the default chosen one that you can write things in, or Scala. And they say that a way a lot of people do the transforms is functional. So if you want to learn something, maybe that's a good way to go about it. So I've kind of been looking at that a little bit, but it hurts my head. Like, it is so foreign to me. is functional so if you want to learn something maybe that's a good way to go about it so i've kind of been looking at that a little bit but it hurts my head like it is so foreign to me so it's totally not where i thought you were gonna go i don't know where you thought i was gonna go so so a little background here a friend of ours told us about this great project that he had heard of that apache uh had been working on.

And it was great. And it had all these great features, right? These amazing things that it could do. And like all of us were like, oh, that sounds great. That sounds amazing. Or at least the majority. There might have been like one or two out of a handful of people that didn't buy into it all the way. But for the most part, everybody was like,

oh, no, that sounds great, and just took him at face value. And it turned out he totally made up this Apache project. I swear, when you said this Apache project, I was like, oh, God, here we go. Apache Indigo. That's what he called it. The thing is, the name is so good that it was so believable. I didn't want to give the name out,

because now it's out there on the internet. Now it can become something. Now it's going to be a project. And then he'll be like, no, see, I told you. There it is. I'm sorry. Yeah. Way to go, man.

You just broke the internet. I did. All right. So now it's time to roll into the episode. Let's get this rolling. So what's our topic today? Yeah. So today we're going to be talking about application caching.

And just to give you some context, last episode we did a bottom-up approach. We talked about some hardware latency numbers that, quote, all programmers should know. We had a great article and some great numbers that we pulled from there. And we talked about basically relative speeds of CPUs all the way up to sending packets across the world, which was 300 million times slower. And we were building up to basically talking about caching and how basically storing a smaller subset of your data in a faster, closer memory location can make an astronomical difference in your performance. And when we're talking about performance like this, it's not so much about saving some microseconds,

it's the difference between being able to do something and not being able to do it, frankly. So knowing these numbers can help you make really smart architectural decisions about your application. But today, we want to focus on something a little bit more practical to actual day-to-day programmers. The kinds of things and decisions that you make on a daily basis and the kinds of things that are available to you if you're actually building an application.

And we're going to do that by focusing in on one specific framework. Now, don't get scared. These are principles and these are the kinds of things that are available in all sorts of frameworks that are similar. So this is going to apply to you no matter what you stack your work on. But we are focusing today on ASP.NET. Only the greatest possible programming. No, it's just the framework that we mostly work in day to day.

I can't take you serious. I mean, for the people that like Java out there or Python or whatever, I mean, it's just the tools that we use, right, that we're the most comfortable talking about. But again, like you said, the concepts apply across the board. So, you know, ASP.NET is the web version of the C Sharp library or the code that we use, the language. And, you know, that's it.

It's just easy to talk about web as far as caching because it's something that people can kind of understand because there's so many different layers of it, and it's easy to talk about those different layers. So, yeah, we're going to start and talk about this a little bit. Yeah, and so ASP.NET is an open source. Crazy, I know, right? It's an open source framework.

I like how you say that now. If we tried to have this conversation a year ago, then you wouldn't be able to make that claim. No, not even close. No, but it's true. It's out there. It's crazy. Open source framework for creating web applications and web services.

And it provides tools for dealing with things like web requests, responses, cookies, sessions, utilities for encoding HTML, what you call it, URLs, all sorts of stuff that's just dealing with writing websites and services. And it works in conjunction with.NET, which is a much bigger entity that deals with stuff like system IO, file systems, systems networking all the kind of um you know more general programming type stuff and i'm curious so you guys are both obviously very familiar with asp.net but why would you choose to work in something like asp.net over say

ruby on rails or no js the tooling is probably like visual studio is just an amazing ide so that's one and honestly i couldn't have said this a year ago like we were just talking about with the open source thing but now the fact that it is truly going cross-platform with asp.net core that is one of the reasons why like at one point no js was one of the things that i was like sweet i can put this anywhere right but now you can do that with with asp.net and that to me is huge so uh the ide and the cross-platform ability of it now so i do i i'm with you on the ide that is one thing that i've always uh loved about any kind of uh development on a microsoft platform that Visual Studio is just always, I don't know. I know some people just truly hate it,

but for me, that has never been the case. But honestly, I gotta say, if I were starting out all over again, I think a big part of why I ended up in C Sharp and.NET was just the momentum. Having already come from MFC, for example, why I ended up in C Sharp and.NET was just the momentum. Yeah. You know, having already come from like MFC, for example, and Win32, and then, you know, it was just the next progression was, oh, it's.NET, C Sharp, right?

And so the momentum just carried me there that if I didn't have that momentum and I was starting over, I don't know, man, I'd probably be really tempted to like a Node.js, for example, you know, a Ruby. I mean, those sound, you know, amazing. You just don't get Visual Studio. So I'll tell you why I or when I would choose ASP.NET for a project. When the project is big, when I want the benefits of a static language, being able to have like compile time or rather edit time in Telesense, if I'm going to be interacting with a lot

of different libraries, if I have a very large code base, like millions of lines, and I'm making a website, I want it to be ASP.NET over, say, Java or Go or any sort of other static language. Basically, anywhere I want a static language and a website, I want ASP.NET. If I'm doing a little hokey site that reads from API and some sort of calendar, just some sort of small application, 2,000 lines or less, then ASP.NET is not my go-to. I would do that in Node.js or PHP. Or I wouldn't do PHP, sorry.

Ruby on Rails, something like that. No, you heard it here first, guys. He said he would do PHP. Hey, but tell me this, though. You said that you would do ASP.NET over Java. Why that distinction there for a lot? Because, I mean, there's Java Enterprise and there's lots of apps written in Java.

So why.NET over that? C Sharp is the major reason by far love the language it's got a ton of advantages i mean link it right there is enough is enough reason to choose c sharp over link for over java for me but also um there's some stuff it's this is pretty pathetic but java is such a huge ecosystem that i just get kind of overwhelmed and intimidated by all the choices that i have even for just figuring out how to build my project and so I don't want to do a freaking research project on like maven versus gradle before I even get to starting on my site yep I was actually going to say the same thing that was one of the attractive things to me for dot net was the fact that

there's typically like there's there's sort of, the standard way of doing things that's easy to follow. Like entity framework is one of the most popular ORMs in.NET, right? Like that's almost always a de facto choice. Um, like just certain things are so much easier to pick. Whereas if you go over to Java, like there's this whole world of choices, which is amazing because it makes the community better, but then it's always, always well what am i giving up to do this like it's it's a lot of decision making and that can really wear you down well i'll be curious to see though like i mean i feel like i feel like we're your argument gets to pick uh the best of what you want it to be though because like you get to pick that it's open source well that just happened right you get to pick that it doesn't have all the you know um the options that

the job environment has you know you mentioned like uh maven versus great over you know and hey for some that's actually a huge plus on the java side is that they do have options like that but again because you know it is so new to be an open source like there are a lot of those options that haven't happened so this is the 1995 version of java right like like open source when you talk about dot net being open source like it's the 1995 version of it it's that in you know that much in its infancy yeah so it's kind of like well i don't know if you're really comparing apples to apples when you when you make some of those claims i mean i hear you and i i don't i don't disagree with it i mean you know there's definitely uh you know the the complexity and

the choices that you have out there i mean you could definitely do a whole uh thesis on it if you wanted to. On the when I wouldn't choose.NET though, it's when I want to play with something new. I mean, in all honesty, like no JS, I do it because it's fun. Yeah, I mean, ultimately for me, it's all about developer productivity.

So if I feel like I'm going to save more time by dealing with Visual Studio and kind of a heavy IDE, then I'm going to do that. If I think that I'm going to be able to use a lightweight editor like Sublime or Visual Studio Code and I'm going to be able to get away with JavaScript and that's going to be a quicker solution, then that's what I'm doing because it's all about saving me time.

Well, I mean, let's go back to the IDE as a point and then I'll stop harboring on this topic. But, uh, you know, I mean, if we're talking about like JavaScript as an example, cause that was one that he just mentioned, uh,

I mean, WebStorm, I love WebStorm. It's amazing. That is an awesome IDE. So, I mean, I actually like it for doing my JavaScript over visual studio.

So, you know, I mean, there's, you could stay in a nojs environment and still have an awesome ide oh uh going back to real quick when would you not use dot net so we mentioned java.net mostly kind of the same but i mean in terms of what they offer you're probably gonna get some some it might get a little bit of flamey on there but but so what we talked about the meetup that

we went to with elixir on top of phoenix right like if you need reliability uh so what that's the other way around or other way around top of the looks yeah so reliability might be one reason right like uptime could be one to where you choose a different framework another one could be parallelism like that's actually a great point so i'm sorry to interrupt but uh you know the guy the guy who was doing the presentation worked for a company that you could say that they weren't doinglang as well, because they wanted the, the uptime, you know, the ridiculous number of nines for liability that Erlang makes his claim for.

Yep. And then there's also other languages that are fantastic at parallelizing tasks. So if you need a lot of concurrent processing or something like that, so, so there are other reasons other than just, I guess what I was getting at, is there might be other real performance or reliability reasons

where you might choose a different platform over a.NET or a Java or a PHP. Functional reasons, you're saying. Yeah, yeah. So that's another thing to think about. Yeah, because when you talk about like the, how did you word it, the threading? Like concurrent parallelism, computing, whatever.

Like that's that's uh goes go is big on that yep i won't call it a claim to fame but whatever you know one of the things is touted for yep so those those are some of the things to keep in mind yeah like for example i don't really care for javascript you know i like the structure and i like the benefits to go along with stat typing however 90 of my side 90% of my side projects are in JavaScript because I can do something simple like GitHub pages to be able to share my work with other people and I don't need a server.

I don't need to set up a website. I don't need to upload anything. I just kind of do my Git stuff on command line and I'm able to send a link to somebody at the end. So that's a huge benefit. That and you love JavaScript. All right, so also we have here in the notes that when it

comes to writing ASP, there's two major sides to it. HTML templating, Razor,.liquid, and you have your compiled language, your C sharp, your VB, F sharp, any.NET language that gets compiled down. The funny part though is where we mentioned the HTML

templating with the razor and all that, I feel like that's somewhat going away with all the front end frameworks. Now, like razor used to be a huge deal in the MVC world, right? Because that was your view, right? Nowadays, it's almost like this though, if you're like truly in, if you're doing only an MVC app, but a lot of people are going towards angular or react or yes, that's the thing. Yeah, I totally agree with you there. So when you get to your single page apps, your spas as they are. You might use C Sharp on the server side, but you're not using it on the front end.

It's your middleware. On the client side. It's really your middleware. It's what everybody calls your middleware. And that's what.NET becomes at that point. And then you have your client stuff and then your storage, right? Yeah, five years ago if i asked someone what template you used they would have talked about razor or one of these alternatives

now if i ask what template someone uses they're like oh you mean like handlebars or mustache or right you know that stuff is really kind of moved over to the client and i like uh mvc because it kind of uh it caters to that a little bit more it lets me have that flexibility so i like that i don't have to spend too much time in template land if I don't want to. I like the front end. But that's only part of it. Yeah, it is. I mean, you can totally,

you don't need to have any razor. You don't need to have any sort of templating or any sort of HTML at all in your C Sharp project for our ASP.NET project. You can do everything via web services and interact with JavaScript. And that's because there's a whole nother side to this, which is basically the compiled part where you can do stuff via web services and interact with JavaScript. And that's because there's a whole other side to this, which is basically the compiled part where you can do stuff like C sharp,

visual basic F sharp, any of the things that compile down to the.net intermediary language. Yep. All right. So I guess now it's time to sort of talk about what we were, what we're here today for. And that's the, the caching,

right? So we've, we've kind of lit up, we for. And that's the, uh, the caching, right? So we've, we've kind of lit up, we talked about the hardware in the previous episode, and that was kind of to get you warmed up to the idea that there's this thing that exists in everything that we do that we don't even think about, right? Like we kind of get it for free because Intel was smart enough to do it. And now we're application programmers. We need our programs to be faster. We need to think about the same things that the people did on the hardware side except now we've got to do it at multiple layers and so we want to talk about what it's like to actually cache in an application um and we've got in the dot net

framework and this is this is kind of the more traditional way of doing the dot net stuff and we're going to hit on some of the other like mC type approaches to things as well. But there's a few types of caching that they give you the application cache, the page output cache, and then the attribute caching is more the MVC type route. And there are tons of things that go on as far as caching anytime you're doing anything. So you've got the GAC, NuGet, all kinds of things, even the browser, but we are focusing on.NET. ASP.NET. ASP.NET. Good point. All right. So what are the benefits? Yeah, specific to caching in your web application framework of choice, the kinds of things you get here are basically reducing database and service calls. And that also means reducing the load on those servers as well. So you need less of them and

a lot less headaches there. It reduces the overall network traffic, which is nice, and improves performance. And as we mentioned before, improving performance isn't always a matter of milliseconds. It's a matter of being able to do something or not sometimes. Okay, so here's a thought. Going back to last episode, right? The number one takeaway that we had from going through that and going through all the numbers and, you know, like, especially when we started putting those numbers into numbers that humans could actually understand, right, was that the closer you were, then the faster it was, right? Like that was that, you know, so and even going back to our how to be a programmer series, I believe it was, where we talked about, you know, your biggest bang for buck is going to be if you have to do any kind of refactoring or, you know, for performance

reasons, right? If you're trying to like attack something to make it perform better, your biggest bang for buck where you're going to see the most value in your time is going to be to go after those things that are, you know, that are making network calls, right? Where you're, you know, where the distance is great, right? It's further away from you, right? And the same principle here, you know, is going to apply here, right? That from the last episode is that, you know, if you can keep that cache, that data closest to you without having to go outside of your system to another system, then you can gain performance, you know, seeing a performance improvement from that. So one thing I do want to clarify here, though, is we say reduce

network traffic. That's if you're storing in memory or on disk on the server. There are other types of caching mechanisms now that a lot of a lot of companies use, especially when you have a large server farm, where you might be using a Redis cache or some sort of distributed caching mechanisms now that a lot of a lot of companies use especially when you have a large server farm where you might be using a redis cache or some sort of distributed caching mechanism so the goal is there is to reduce the cpu processing to get these things but we'll talk about that a little bit more but i did want to touch on that real quick before we jump too far ahead so what's the cons then why Why would I not want to cache? Because so far it sounds amazing. Right.

You tell me. Well, kind of annoying. Okay, so it's annoying. So, so, uh,

there's the real possibility of having stale data. And how do you know if the data is stale? When you decide that the data is stale, like, um, we'll get to an you know an upcoming episode you know we hope to talk about caching algorithms but uh deciding when to invalidate something from the cache i believe that was like one of the the two hardest things

um that that for a programmer right one of them was you know right invalidating the cache uh the second one was naming things. And the third one was off by one errors. So the very real possibility of stale data and how to deal with that and how to know, that's one con. Then there's the complexity. There's the complexity of not only dealing with

the knowing of the stale data, but then the complexity of the whole caching mechanism, you know, whether you use something built in, or if you decide to roll your own, or if you decide to use a third party that you have to integrate, like what Alan was suggesting, that may not be physically on the same box. So you might have to make a network connection, but hopefully it's a closer network connection or faster because it's only dealing with key lookup values or something like that.

But there's still the additional complexity that you have to add to your system. And then you also need to make sure too that depending on how that's implemented, that that then becomes the single source of truth so that all of your calls for whatever that piece of data is, they're all going through that same funnel so that they can all show it. Because the last thing that you want to have happen is 90% of the calls use this cached value. And then this one other guy over here, you know, just goes off and

and re queries the data on its own, and is always pulling up a live view or something of the data, but never taking advantage of that cache, right? And then, you know, what happens if it's, you know, if the two are out of sync, right? So yeah, complexity. Yeah, even adding to that, if you've got more than one server, right? Now you have to start thinking about things. And so you can't just necessarily do in memory caching because, you know, this server has one thing in its cache, this server has another. So then you have to start thinking about a distributed cache or, or do you care if that's, you know, this goes back to, you know, what is truly stale data? Like, do you care if they're out of sync? Like there's so many questions that you have to answer. Or, or maybe, uh, maybe you don't care that each server has its own

in memory cache, but in that case, now you got to think, okay, well I have to set up like sticky sessions, right? Like, yeah, there, there's, there's a whole level of, uh, you know, complexity that you got to think about if you're going to start adding in cache into your system and where you're going to add that in. So if it's further away from the client, then there might be more touch points that you have to think about. One other comment I just thought of, if you're the person that sets up the caching and you are the person now that is the front line for problems, because the first thing anyone does if there's any sort of cache involved

is point to the cache person. Like, I don't know, man. That's cached. I don't know. You know, talked out law. That's right. He wrote it. We can't even look at it, man.

That is foreign code. I feel like you just threw a dagger at me thanks that's awesome all right but it's not but it's not but he's not lying no it's true absolutely because people are like oh but we know that data is there oh it must be a caching problem like and it really is a complex problem for that very reason like everybody has a different idea about what they want to see I totally forgot a con about about cash is that you should absolutely not use it because carry a credit card man because here's the thing yeah cash is king because here's the thing that I forgot about too it just Joe reminded me when he when he made his joking comment about everybody's going to go to the cash guy. Because not only is, like, if you are the guy that happened to implement that,

and like, it doesn't even have to be, you didn't have to roll your own. You could just be using the built-in stuff. But every time there's a problem, they're going to, it's going to be blamed on the cash. Absolutely. Even though it's not, they're going to blame the cash. Oh, that must be a cashing problem. So you know what? I take it back. Don't use cash. Don't use it. It'll make your life so much simpler. All right. Ignore what he just said. We're going to, we're going to tell you why you should use it in different ways. You can, um, we already told you why, right? It just speeds things up. It does come with problems.

So one of the first things we want to talk about is the application cache. And this one's actually pretty simple because it's just key value pairs. So basically when you get into this thing, um, if you cache some piece of data, you give it a name, right? Like, um, I don't know, number ID. Yeah, user ID, right? So that's it. Whatever value is in that cache is that one. And until you clear it out, it's going to continue to use that one. If you try and assign to that, it will overwrite the cache. It'll refresh it. So it's such a simple one.

It's your basic dictionary or your hash table. That's really all it is. It couldn't get any easier. Yeah, I'm trying to think of what it might look like if it wasn't a key value pair like that. But, okay. I won't put you on the spot. Say what? An array?

I don't know. Are you talking about what's being cached? Just the overall cashback. That's a terrible way of doing it but i was just trying to think about an alternative approach yeah i mean really a lot a lot of things all kind of boil down to that to some degree just about right because you have to be able to reference what's in the cash um there are other methods that we'll talk about here shortly. They kind of get into some of it, but that's just your simplest type way to store value, to cache the value, to refresh the value, whatever. Yeah. Well, it's also the fastest,

right? Hashtables have a, you know, a big O lookup time of O of one. It's constant time to look something up. So if you've got the name for it, bang, that's the way to go. You don't want to be traversing a tree or looping through an array to try and look something up you know it just doesn't make sense if you can just kind of stick it in there and look it up immediately yeah yep and we had some good uses here uh for for caching for for the key value pair type stuff so like looking up your common site settings right that might be one well i decided not to use cache at all but that's right well i mean don't even think about don't think about cache just for a minute now think about it like variables like if you've got say a web config

file every time you access and that's basically a config file that's where you store common settings on on disk and then your application can look that stuff up so if you need to make some changes to this file you don't have to redeploy your whole app it's um it's a common convention in many applications and as we talked about in the 12-factor app a lot of times you can do this in like environment environment variables or other places but anyway point is your web application framework will load these settings once or periodically And so every time you reference one of these settings, it's not going and doing that slow file system lookup. It's reading that stuff out of memory because it knows that those settings are going to be accessed often. So that's a great use for kind of a different kind of caching. But same idea. Basically, you've got something

that's slow, but you stick it in memory where it's going to be fast and cheap. Yep. Well, here's another one that anybody can relate to, regardless of technology stack, would be database connection pools. And depending on what technology stack you're using, you might get that built in for you a little bit more than others. Yep. Another great example is user information. Like for example, I think it's common if you're doing any sort of like website work

to want to know what the person's name and email address is. You may need that for all sorts of reasons. You might want to say, hello Joe in the top left. You might want to send me an email on some sort of action. You might want to access my user ID based on my cookie for all sorts of reasons. So these are the kind of things that make sense to look up, say, at the beginning of a request or the beginning of a session and cache that stuff for faster lookup because you know in the life cycle of me using your application that you're

going to need to access that data hundreds of times. And that's not stuff you want to look up from the database hundreds of times. Yeah. And in that example, right, because this is we're talking about from a server point of view caching this thing. So like the user info, the key might be user ID, and then the value might actually be an object containing all your information, right? Like your first name, your last name, last time you logged in that kind of stuff, right? So key value pair doesn't necessarily mean that it's just, you know, first name is this last name, last time you logged in, that kind of stuff, right? So key value pair doesn't necessarily mean that it's just, you know, first name is this, last name is that, because this is a shared cache. So it wouldn't make sense to have just a user ID or user ID key in there.

So having an actual ID with an object type in there is the type of stuff that you can do with that. Well, you know, we keep talking about, I don't know if we wanted to get into, like, some of the actual implement stuff that you can do with that well you know we keep talking about i don't know if we wanted to get into like some of the actual implementations that you might use or not but you know we keep talking about this in the frame uh you know the conversation has been framed as a web server uh you know we keep kind of talking about it like that but you know there's caching mechanisms built in not to asp.net but if we're just talking about like general.net there's caching mechanisms mechanisms that are built in to just the core language that you can use as well so i mean i don't know if we wanted to go over some of these

um you know but we can uh i mean like for example so we were talking about in the web server, or as Vlad would say, web server, kind of conversation. Then there's two ways that you could do this. If you wanted things to stay cached across your server, across request for multiple requests, right? Then there's the HTTP runtime dot cache property, right? Which I forget that guy was like an implementation of system dot web dot caching, right? But there's a generic version of the same thing for like desktop application as well that's system.runtime.caching object cache class and both of them you know like what you said alan you you could do your your key

value pair kind of um uh you, how would I say this? Lookup or cache? Storing. Without saying cache? Storage. There you go, storage. I like that word better. You're saying key value pair storage.

And, you know, but if you wanted it to stay, if you wanted to cache something within a specific request, right, and stay within the request, then one thing that you could use is use the http context.items property. And so you could stay at the request level for that. So maybe you've already taken the time to look up some stuff for this particular user, and you've got a lot of other calls that you need to do,

and you don't want to have to look that up again but you want to be available then you can use that guy right yeah very cool yeah we didn't really even talk about the different kinds of um life cycles that are um or rather scopes that are uh there we don't want to get too deep into the framework but when uh outlaw's talking about requests he's talking about an actual HTTP request issued by your browser. Like you say, go to www.codingblocks.net slash episode 46 and that's a request. Your browser is going to send me the request for that website and that webpage. And WordPress in the background

is going to go through a request lifecycle, gather up all the data that it needs from various caches because you know WordPress is caching the crap out of stuff. And it's going to put that stuff together. But also web frameworks, including WordPress and PHP in general, have a notion of a session as well, which is basically, it's a, how do you describe session? It's just a way to tie different requests together, right? To make it look like it's a how do you describe session it's um it's just a way to tie a different request together right to make it look like it's the same user so groups that stuff together so like it's not

going to try and authorize your username and password every time you request a single web page right it's going to give you some of the cookie that ties those requests together and it's going to be valid for a certain amount of time or um or it will time out after a certain period of inactivity and you know that brings up a good point i never really thought about session as a cache but it kind of is right i mean people use it as a cache a lot of times and you can get a lot of memory pressure because of that but that is one way that it's done and then you also have your application cache which are variables that are shared by everyone that uses it right like the

application name could be coding blocks and then everybody who accesses that variable gets that same thing like a connection string for your main database that's something that doesn't normally change during the the lifetime of your application unless you're doing some really funky cool stuff but that's something that can kind of be picked up once and unless you restart that application no need to keep checking for it and so we cache that at the application level so that's something that common to all web frameworks and it's common caching as well but it's it's it's all the same principle we keep a subset of our information in a closed location so we don't need to hit the database server or the dose sql server or whatever else we're doing we don don't have to keep hitting APIs for information,

if we can just kind of keep that stuff around for a known amount of time. Yep. All right. So now we're going to get into another part of the framework, which is the ASP.NET framework. And this is the page output cache. And I've heard this called different things in Java as well. But the page output cache in.NET is basically you make a request to a webpage. The first time it serves it up, that page, the server goes through, creates the page. It will then save that in cache. So the next time, like I hit page one, it gets built and it gets sent back to me, but then they put it in the cache. The next time Outlaw goes and hits page one, then it's not going to go try and rebuild that page again. It's going to go straight to the cache and pull it out.

And then if Joe hits it after that, then he's also going to get that cash thing. Now, the problem is when does that go stale? You know, again, we'll talk about that in a little bit, but that whole notion is fairly easy to understand, right? Like the first person that hits it, it does the work, then everybody else after that gets the benefits of that first hit. And that is the whole page, by the way. So the entire page, top to bottom, every bit of content that's in it, that's the page output cache. So the first time it's created, even if there's a date that was written on that page, if you weren't smart enough to omit that from part of it, then that same data is going to get served up every single time. Assuming

that it's not JavaScript, we're talking about all server side generated stuff here. So you probably want this to be something that's going to be the same among users that so you're getting at. Yes. So like, for example, if you wanted to um cache your sitemap or or better yet well um i think when i said sitemap though i immediately thought of like a google sitemap but i was originally thinking of like maybe a visual representation that you might show to the users but i suppose you could do either if you wanted yep i mean even a good example is uh like even our podcast right like every podcast that you see in iTunes has a podcast feed. It's just a huge XML file, right?

That goes through. So that's maybe something that if somebody hits that page, you want to cash it. You don't want to regenerate that thing because it could be expensive. It's having to crawl through your database, get all the metadata, all that kind of stuff. So the first time you hit that thing, you want that thing cashed so that the next hundred people that hit it, it's the same thing that's being served up from memory. And it's not having to go through all the CPU intensive stuff to recreate that. And it's PHP.

And I heard that Joe was willing to do some PHP. So I feel like that's a win. Yep. Could you imagine if we rebalanced the episode every time someone requested it? Or every time someone requested it, or every time someone requested it, we all got together and recorded it again. So now you're calling the file itself as a cache, a cache of this meeting.

Yeah, so reducing redundant work. Yeah, I mean, that's really what it is. Now, one of the interesting things about the ASP.NET page output cache is it will cache not just the interesting things about the ASP.NET page output cache is it will cache not just the URL that's hit, but it'll also do it based off like a user agent. So if you call it from an iPhone, it can cache that one individually. So everybody else that comes from an iPhone, they'll see that same version. You can cache it for Android, you could cache it for Chrome, Firefox, whatever. So you have the option in the ASP.NET page output cache to define the level of granularity for how

you want to do it. So you could do it at the URL, or you could also add in the other things like the user agents and all that. I kind of take it in different directions. So I don't know if you want to go ahead and go ahead. Well, the one last thing I was going to say, though, is that it does, going back to the conversation of, how was it worded? Something about when we brought up Razor and we were talking about the templating, though. It kind of feels dated, though, because it's like, man, nobody's, you're not,

is anyone really writing they're using this this output page cache you know using something other than like an angular or a react or something like that for the front end to where like this is even relevant anymore like that part no man that's the spa tyranny that's oppressing your mindset. Spa is not the only way. We built websites for a long time before spa was a stupid acronym. And we will be here building pages. I will be here building pages long after spa is gone. Preach on, Grandpa Joe.

Yeah, man. There are so many times when I don't need an app. Oh, man, there's a movement. Hold on. Let me get your new Twitter handle it's a real quick you know i'm the crust of this wave oh man that's amazing oh hey before we move on from this there's also so that was the entire page output cache so now this is going back to more the web forms way of doing things in asp.net but it's worth even more, you know, even older. Yeah, this is good.

This is going back to grandpa Underwood a little bit. Um, so there was also the notion of in, in web forms, you could create user controls, right? And those were basically components that you could drop in various different other pages, 10 times, 50 times, whatever you wanted to do. You could also cache those things individually as well. So let's say that you had a page that you wanted to display and most of it was static, but then there were other pieces of components that you either wanted to turn the cache off for, so it was always fresh. You could do that. Or if the whole page wasn't cacheable, but that one component was, you could also do that. So you could actually get the benefits of caching just parts of a page, as opposed to the entire page itself, which can be

useful, like it going back to that whole time thing, right? Like, let's say that you return the server time, that's not something you want cached, because that changes every second, right? So maybe you had a component that displayed, you know, hi, Joe, it is now, you know, 5.30 PM your time, then that's not going to be cashable. Welcome to my 1995 webpage. That's right. And ignore the spa thing. But going back to it, so that spa thing, so let's say your application is that way, but you still might have things like, like what a robots.txt type file, something that you might actually generate on the fly.

We've done things with e-commerce sites to where you have to create like product graphs, right? So that's the kind of stuff that you don't necessarily want being built on the fly every time because that's CPU intensive stuff. And it's also a database hit, right? Like you have a hundred thousand products in your catalog. You don't want to be creating a page with 100,000 line items that are being, you know, have a bunch of metadata created the entire time. So, so there's still a place for caches like this, it may not be in your pretty spa, that's only going to load one page and have, you know, 500 JavaScript includes, but there are definitely times that you would want to use

this output cache mechanism yeah and actually you just reminded me of the best kind of cache static site generators i'm looking at codingbox.net right now our comments are dynamic we need those to be you know shown people can add stuff we want that to be interactive we've got some tweets on the right nothing else changes on an hourly or even daily basis. I mean, this stuff just doesn't happen. If we took these requests, just issued some standard requests and went through each article,

we could totally generate static files, save them to disk, if not memory, and then every time we get someone visiting the site, we just serve up that single file. So now instead of hitting the database server, hitting the various services, hitting the API, running through logic, we're just loading a file off disk

and sending it right back. Which, by the way, we kind of do that anyways. Well, that's not exactly fair, though, because there's the search. Oh, we do have a search. It doesn't work like what, that would not support what Joe was just describing. But yeah, if we didn't have that, I'm with you there.

Who uses site searches, man? Google. I actually do, believe it or not. I search on our site sometimes because we have lots of great content. I go and search. Alan said something crazy, and I had to look it up to prove him wrong. Oh, wait. No, I was wrong.

Man, the internet's broken. I can't trust this thing. But it's a great example. If you have an e-commerce site somewhere that you're getting hammered, even if you show something like inventory that does change minute by minute, there's no reason why you can't generate the static parts of your site, save them to file, and just display those pages and kind of pop in those places that do need to change with JavaScript or something like that. So that's a great way

to really reduce your CPU on both your application server and your database. And so that's a really extreme example, but it's a good one. Yep. And that kind of brings up another point, though, that was key here, and we probably haven't mentioned somewhere in the show notes down below, but there's different types of caching. You don't just necessarily cache to memory. You can also cache to disk. You can cache to a database. You can cache to multiple different places, right?

So what you just said, you could literally generate that page and save it on disk because it's still faster to go get it off the disk than it is to query the database process all the stuff right out there you forgot to make your connection to the database and you open your connection overhead of getting that connection yep so i mean even then it's all about reducing the steps and how warm it needs to be or how fast you need to be able to get to it so um it with that the next pieces that we had here were like the the time that you can cache so you can cache you can say hey i just want this cache for an hour right and no matter what happens in the hour it's going to end and then it'll have to be recreated what were you talking about because i saw this in the notes and i thought like you were specific to your page output

cache still this is the page output cache okay yep This is the page output cache. Okay. Yep. So you can cache that for a specific period of time or like we already mentioned the browser versions or you know locale information like language for example. Yep.

And you can also... Go ahead. So one thing that's kind of cool about ASP.NET and probably other web application frameworks as well is things like a settings file that we kind of mentioned earlier, those are the kind of things that are loaded when the application loads and aren't typically loaded again because why would you? However, ASP.NET and probably other web application frameworks

do watch those files. So if you make a change to like a config file, or web config file that it's aware of, then it's going to reload itself. And so it feels like those settings are real time, but they're really not, it just happens to know when it changes. And so it's able to restart the application, which is really slick. And that kind of leads to the last part of the page output cache is you can evict cache entries based on events. And that event might be exactly what you just said, right? Like a config file changed on the disk or, you know, some other file changed or a database entry changed. Oh, the worst?

ASP.NET, by default, every 29 hours will recycle. Really? I don't know if you guys have had problems with problems this uh yeah it's really weird and it seems it's off because it'll happen at different points no yeah man it's causing me some heartache because you want to know the with three of us have totally hit this before 29 hours that that's so random i should remember it i don't at all holy smokes wow that's that's terrible apparently it's not burning do your memory the same way. No.

That's actually an IIS thing, though. It is, and that's not a requirement for ASP.NET anymore. Oh, really? So.NET Core is better? Oh, yeah. Well, it wasn't that it was a requirement before. It was just an IIS default. Just what they did.

Yeah, but who on earth was running ASP.NET through anything else but IIS? Besides Vlad. Nobody did. Vlad was. Okay. So that's a good point. But, yeah. Well, because at the time there wasn't another option. Yeah.

Except for Vlad's, which I'm about to mention as soon as I find it. What was the name of the web server? Oh, crap. Vlad Ry, which I'm about to mention as soon as I find it. What was the name of the web server? Oh, crap. Vlad Rybak. I can find it real quick. It's like... Oh, come on, man.

Everyone can listen to us all Google. This is where it goes off the rails. Who has the best Googling Googles? Web server. I'm going to Google for I am Vlad. I write web server. Oh, come on. Where is it, man? This this is gonna drive me crazy well we were terrible i guess we'll have it in the show notes but i feel bad man he's uh he really wrote a really awesome web server that's used by like what a million people

ulti dev yeah that's it yep so yeah he he actually is one of the few people that didn't use IIS. altidev.com Yep. So, all right. So the next thing is method-level caching. Joe, you want to fill us in on this one? Yeah, and this is something that's specific to MVC and Web API, and they've kind of combined now, so I won't even bore you guys with the details.

But what I really like about it is that you can annotate these things, which is something you can do in static languages where you basically, in C Sharp anyway, you put some brackets above and you can kind of provide some special instructions like caching. And so you could have some brackets and then specify like a cache period

or a particular type of caching or just all sorts of information that makes it easy to cache stuff. So for example, I have a website that does some color calculations. It's really boring. I won't bore you with details, but I get a lot of the same requests, like people comparing, say, red to blue over and over and over again. I don't want to do that work all the time, so I put some caching in place. And so if you keep requesting the same information over and over and over again, it actually sees the two inputs coming in, uses that as the key for the cache and then it doesn't

have to redo those calculations and it saves itself a lot of time because people do for some reason do a lot of repeat calculations so this is actually not at all specific to asp.net though so So we've talked about aspect-oriented programming before and how awesome it is, right? So if you use PostChart, for example, they actually provide a really nice example in their documentation

about how you can do cache the results of a method. And you would decorate your method with an attribute, as you described, and, you know, you can just use an aspect to do it. So, so there is the.NET way that you described, but then there's a, you know, this aspect-oriented version of it as well. And, you know, other aspect oriented frameworks might allow you to do a similar thing, regardless of language, right? So, you know, we're calling it an attribute in.NET, but it'd be an annotation in Java. You know, so maybe your language of choice, you know, for aspect oriented programming might give you a way to do this. And I'll include a link to that

as well, because it's really cool. Cool. Also a couple things it looks like some of the show notes got a little bit out of order here but on the page caching thing there were actually two different types. There's control caching and fragment caching and this goes back to the user control type stuff and then there's also the post cache substitution which I thought was pretty interesting. So you can cache the whole page, but pieces of the page are substitutable. So it's kind of weird, instead of everything happening in line, like after the page is built, then it'll go and swap in content. So that's pretty interesting. And then the other thing to be aware of is you can do it on a page by page basis, like in the, in the definition of the page itself, or you can go into like the web config and you can do like entire files or directories in bulk in there. So it's easier

to set up. So there are multiple ways to do that kind of thing. And that pretty much wraps up with the, uh, the page level caching. All right. So, all right. So I lost my place for a moment, but so we're done with that part. So you know what? I'm going to just go ahead and say this, okay? This episode is sponsored by, well, it could be you. So if you would like to be a sponsor of this podcast, contact us.

Oh, you know what? Which email did we want to give out for that? Just send it to comments at CodyBlocks.net. Or if you want, you can go up to the contact us page at CodyBlocks.net slash contact. Either which way, just reach out to us and we will definitely get back to you. Yep. And you could hear your company's lovely name mentioned by one of our voices. They all sound the same, so you're pretty much getting a deal

because it's going to be a win-win no matter who says it. That's right. I'm the fast talker. And you can request which one of us, by the way. So, yeah, you can get Mr. California slash Southern. You can get Mr. Fast, yeah you can get uh mr california southern you can get mr fest or you can get egon if only you could see him doing that that's amazing pleased yeah i feel like i gotta ask who you're gonna call

ghost but a banner you went too far too to handle, too cold to hold? Oh, man. Yes, you did. That's amazing. What's up? As I choke over here. Thanks. Oh, that's awesome.

All right. So I also want to say this, that if you haven't noticed by now, we're a little needy and we really we really would like you to tell us that we're pretty and that you like us by heading over to www.codingblocks.net slash review and you can find links to either itunes or stitcher and leave us a review if you haven't already we we greatly appreciate it um you know i don't know what more i can say about it other than you know it really does make our day when we read a new review and you'd really be doing us a favor because uh you know it helps us out and hey and after you write the review come join us on slack by heading to www.codingblocks.net slash slack and plug in your information and come join in on on the

conversations over there we have some great ones daily so so um you know while we're taking this little break here last time we gave out a survey and it's time for my favorite portion of the show is to see like well how right or wrong are you two? Which you're not really having a good track record, I'll be honest. I was within one-tenth of a percent one time. One time, but you were still wrong. That's impressive. Because you didn't trust your gut and you then went and changed it.

And so your final answer was way far away. But I was so close. Yeah, right. Okay, well. was way far away but i was so close yeah right okay well uh so the question in the last episode was if you were stranded on an island and could have only one programming book which would it be okay now somebody had fun with the uh you know filling out this survey because there was no shortage of books here so i'm going to burn through these real quick. Okay. So here are your choices. Code complete a practical guide. I'm sorry. A practical handbook of software construction, clean code, a handbook of agile software

craftsmanship. This is the third one structure and interpretation of computer programs. Number four design patterns, elements of reusable object orientedoriented software number five head first design patterns six refactoring improving the design of existing code seven effective working effectively with legacy code eight introduction to algorithms nine the pragmatic programmer 10 cracking the coding interview, the art of unit testing, 12, the art of computer programming, all volumes, 13, the practice of programming, 14, clean coder, a code of conduct for professional programmers. I think I'm on 15. Oh, how to survive on a desert Island, 16, rapid development and 17 adaptive code via C sharp. That's because I put an other in there. People could type in their own options. Okay, yeah.

Oh, which one? Where did that start then? I don't have any clue which ones they had. Okay. Okay, so that's why there were so many choices then. Yeah, that is. I wanted people to be able to throw in their own books, right? You really went far.

And then, okay, that now explains the one why it was specific to C Sharp because I was like, wow, why would you really okay well because there were no other ones specific to any other language that's why i was curious i left it open because i figured that was a good way for us to find out like some good books that maybe we hadn't heard of right yeah sure um so on that because the list is so great and people could type in their own thing i'm going to think design patterns one okay design patterns that's your number one pick you care to put a number behind it man that's going to be so hard there are so many choices i want to say 10 10 all right number one design patterns joe what say you 15 for it's between two, but I'm...

Pragmatic programmer. Easy for you to say. Pragmatic programmer. Pretty good. Okay. So Joe thinks that the number one book choice to be left with while you're stranded on a desert island is the Pragmatic Programmer at 15%, and Alan's pick is Design Patterns,

Elements of Reusable Object-Oriented Software at 10%. Of course you're both wrong. programmer at 15% and Alan's pick is design patterns elements of reusable object oriented software at 10% of course you're both wrong I mean how did you not see that coming complete how did you not see that coming the number one choice is of course code complete a practical handbook of software construction at 22%

of the vote wow it had a commanding lead yeah it was actually really impressive wow and then and then you know just because why not uh you know let's go through number two and three the art of computer programming all volumes with a 15 percent uh you know second place. Wow. Now here's where it gets really interesting. Joe? Third place, the pragmatic programmer. Yes.

Nobody cares about design patterns. We've been doing it wrong. Yeah, 12% man. Wow. Yeah, well you were at eight, so you weren't too far off on your percent. You're both pretty close on your percentages there, but yeah, you weren't.

And design patterns wasn't even like, I mean, it might have been like tied later, but it definitely wasn't top three, as I already said. I think it was tied for fourth. So maybe it wasn't too far. Where's Clean Code? Clean Code was the top one. No.

No. Code Complete was. Clean code was the one tied with the design patterns okay so number four okay yeah all right i'll go over that excellent yeah so and you know what hey let's do a survey for next time while we're talking about surveys so the idea for this one was let's talk about your favorite source of caffeine. Because over the years, I've definitely heard people argue about, I've always been a Dr. Pepper fan over a Mountain Dew or a Jolt. But of course, in this day and age of Starbucks,

everybody loves coffee and espressos and cappuccinos and cold coffees. Do you want to taint the jury pool? Throw out your favorite? Dude, I love Mountain Dew. No, I'm stopping you right there. You can't do it. Mountain Dew. Oh, man. You cheated. I'm supposed to do that.

I had my first cold brew coffee thanks to Slack. It was really good so uh i'm gonna have to have a few hundred more before i can really enter it as a true competitor but i would be interested to hear what you guys have to say curious how how did the slack conversation come into this uh we have a beverages channel i believe it's called alco dash code well okay i've seen that but i wouldn't assume that cold coffee would be a conversation that would come up in that you would be wrong sir apparently apparently i am

man a few hundred that's only that's only like a grand at starbucks just so you know oh well no wait like 1 15th of them are free so you know 9 975 or something hey 115 oh speaking of here's here's a stat for you and it's not a real stat um but a pseudo stat for you i had read somewhere that starbucks like they're you know you can charge up your reward card or whatever there's more money in reserves on those things than most companies make in a year really it is oh okay so that's basically like saying that people have money tied up in gift cards yes is the equivalent yep yeah right so i definitely put like 15 bucks on my phone every, I don't know, two weeks or so. It's amazing. They've got a lot of money up there.

Are you not getting breakfast? Come on, man. 15? No, dude. That's not going to get you nothing. I don't get the breakfast until I get my rewards points because then I get that sandwich for free. I can't pay $4 for a breakfast sandwich. I can't do it.

Now, is that... So, okay. So the reason why you put the money on there is for the rewards. That's the only reason. And it's convenient, right? I don't have to break out my wallet or anything like that. Because the one near me, finally, I can do tap and pay. Finally. No, I can't be doing tap and pay. I need the rewards.

No, man. Tap and pay is amazing. Yeah, you get the stars, man. Anyways, all right, so moving on to more relevant things we'll talk Tappan Pay some other time yes tokenized payment systems

so ASP.NET core caching it's extensible it's awesome you can kind of do your you can plug it into whatever you want whether it's redis or or disks or some other database or whatever like it's pretty cool and they say don't roll your own caching implementation dot net does it better yeah i've rolled my own several times but i did not have the ability to customize it nearly as

much as dotNET gives you out of the box and they just have all sorts of cool strategies that you can just configure you know design pattern strategies for for dealing with cache and so while you can set up your own hash table and whatnot why right exactly like they even say so going to the design pattern you create your own provider so they they have this interface that you use as your contract and you just hook your own up and you can be off and running you want to do it to my sequel sure fine postgres okay what mongo db whatever you have the freedom to do it you just have to adhere to whatever contract they have in place for it yeah i was just curious if our words was going to write my own cache provider what would i do it because because sql is already provided right if you want

to store stuff in database i'm sure you can do it to to file right um i'm sure there's like a i know there's a like a dot net session server that you can set up to share uh sessions and and uh cache between servers um i guess you could do a SQLite. Oh, here you go. We should combine things. We should make a Twitter client that will save your cached information out to Twitter and will read that RSS feed back in. It just makes sense.

If no one's done this, this is going to be my next project. You want to make sure you don't cache anything, any personally identifiable information there. Oh, man. That could be like 10 episodes worth, I believe, talking about PII. I don't want to talk about it. Yeah.

One of the cool things about the.NET Core is you can tailor it to your needs. So take an example like you're a heavy e-commerce site, right? Your top 10 pages are uber important to you. Like you want to make sure that those things just pop as fast as possible. You store those in memory and then your less served pages you have cached off to disk. And so that's a way to, to make sure that you're not killing the memory on your server, but at the same time, you're not having to reprocess all those pages anytime that they're served up. So that's, that's kind of cool. And I even had a

little code sample here that you could do in the web config for it. And it's basically a caching tag. You tell it the output cache, you tell it the provider. So ASP.NET or ASP.NET internal provider, and then you tell it, so a disk cache, and you tell it that you're using the disk cache provider, the output cache provider. And, um, that's pretty much it. So it's actually kind of simple. Uh, you can do it on a page by page basis. So you could actually in your directive for the page, tell it that the output cache, tell it the duration, vary by params. So if you change params on the page when you're calling it, it doesn't care or it does care. You tell it whether you're doing the disk cache or memory cache. So it's pretty easy stuff to set

that up. And actually, I just looked up how you would write your own output cache provider, and it's dead simple. You extend a class provider base, and you've got four methods to fill in. Get, add, set, and remove. Nice. That's it. And you can configure it. So yeah, for doing this for Twitter, really not a big deal.

It's totally trivial. And so I'll probably not waste my precious time with it, and not because I will fail miserably. But yeah, four methods, and someone else should do it. That's killer, man. Yeah, you know, I would love to do it, actually, but I'm going to be spending the next 70 years reading The Art of Computer Programming,

volumes one through four. Well, but only if you're on a deserted island though right right only if you're stranded yeah no i have something to prove now i i'm the imposter syndrome's kicking in i can't believe that so many people have actually read any significant portion of these books yeah i just uh i i gotta think though that the picking the all the volumes though that's the smart pick just for you know having the resource to start a fire yeah you need lots of pages point yes i was yeah i was interpreting the uh the um the poll to be uh what's the best and that wasn't

the question so what would you would you take? These guys would make great seats. There's a lot of information there you could read for years out of these books. If you need toilet paper, which one's going to provide the most? Wow. Pulp.

Leave it to Mr. Bidet. Who needs Ambien when you have the art of computer programming? I'm totally kidding. I'm sure these are really awesome books, and I don't mean to make light of them, but it's kind of funny to you. You went the Ambien route.

That's awesome. All right. All right. Thanks, Wilson. Let's get back to caching. So I feel like Alan wanted to say something about... I know better. You don't mess with the idols like newt

say again i was just digging the hole deeper we should just move on uh okay good newt is awesome i'm kidding he's great nothing to see here all right so we wanted to talk a little bit about uh caching and memory so there are some things that can happen with that that aren't so great imagine that like this is some of the the bad parts of caching right so there's this whole concept called scavenging so let's say that you have 16 gigs of ram on your server and all of a sudden all 16 gig are taken up well guess what if the dot net framework decides it needs some of that memory back, it's basically just going to boot some of your items out of the cache. Is that good?

Guess what? You should not have your application server on the same box as your SQL server because this will happen. Oh, no doubt. Well, if you have it on the SQL server, SQL server will just take up all of the memory, period. Because it's greedy like that. But as far as it on the SQL Server, SQL Server will just take up all of it, period, because it's greedy like that. But as far as it being good, though, I mean, this is totally one of the reasons why things can be evicted, as you put it, or invalidated or flushed or whatever word of verb of choice you have for something being removed from the cache.

But even in the examples that I mentioned with like, take the HTTP runtime dot cache property, right? You know, if, if the server determines that the memory is below some threshold, that it that it wants for free memory, it'll start evicting items from the cache, you know, to make room, right? Yep. And there's nothing you can do about that. Like that's part of the framework. So is it bad? I don't know. I mean, I don't know.

It's just part of it, I guess. I can't really answer that question. It's like an unanswerable question. I think it's one of those things that you just really have to be aware of what's going on in your environment, right? Because let's say that you just cashached something, and it was a heavy process, intense thing that got cached. Well, if you've, like you mentioned, if there's SQL Server running on the same box, guess what? That thing's getting kicked out as soon as it got added.

Well, let's talk about something realistic, though, because I feel like that's not. Okay, let's say that you're on a shared server right in uh like in hosting environments or something like that it this isn't necessarily dot net per se but if you're in a server environment that's shared like you're doing uh not necessarily virtual hosting or something but you are literally on a shared box you can't rely on the caching mechanism there because you're contending with who knows how many other different sites on the box or whatever else. Well, you're talking about specific to a.NET type of shared hosting where literally everyone's on the same instance of IIS.

It's just IIS is hosting multiple websites. That single instance of IIS is hosting multiple websites. That single instance of IIS is hosting multiple websites. And in that case, it's the same IIS web server that's running all of it. Well, there's actually a different instance, though, right? No. Oh, no. Well, it could be different app pools, but it doesn't matter. The.NET framework is managing the memory.

So at that point, it can choose to boot them. But at the app level, though, right? Yeah, like it can, it can choose to boot them. But at the app level though, right? Yeah, probably. yeah, that's actually a good question though for like,

I've never looked at how that type of situation, how IS is configured in that situation. You know, if each one's given a certain amount of memory or not. Hmm. Yeah. So, so that's one thing to be aware of.

Like scavenging can happen and you really don't have much control over it. You just need to know. But, yeah, I mean, the example that you gave, though, where something was just cached and then immediately removed kind of suggests like there's some kind of – it kind of suggests to me like there's some kind of thrashing going on, right? Yes.

Because typically it's not going to – because that would just be a bad – well, maybe we'll get into the programming, the caching algorithms sooner rather than later. algorithms that you could use for the eviction could be based on uh you know the age you know how old is something or um you know if it's you know something that isn't referenced often then that's what you would get rid of um so for it to get rid of something that was just cached kind of suggests that there's like you're low on memory there's memory pressure there's no yeah yeah no memory at all and you just cached like one thing because that's all there was space for and it's already reclaiming it then i don't know that sounds like a bigger problem it could happen though i mean because it's not uncommon to cache a result set either right like let's say that you

get a data table back and it's it's lookup values or something like that like it could be any number of things that you could be caching, but it's not uncommon for you to be caching something that's not a simple value. You know what I'm saying? Yeah. Someone could be spidering the heck out of you. Happens.

Google used to take out sites all the time. Well, that's what I was thinking with the thrashing. Sorry. Yeah, totally. I mean, and it may be things completely out of your control like you know it might be legitimate things that booted it out but you don't have control over it so that's one way that things can get uh you know evicted from the cash or what was the other word you said uh flush invalidate invalidate that's what I was looking for. Whatever. Yep. So the other one is

you could literally just have an expiration. You set a date on it, whether it be an absolute date. So you say a date and time. So say at midnight every night, this thing's going to get kicked or you can have a rolling one, right? So as long as somebody accesses that cash, then maybe you add another hour to its life so go ahead well i was gonna say like a better example of the absolute expiration might not necessarily be like at midnight but you might say like this is good for the next five minutes yeah totally totally and then after that remove it yep and that's that's literally there's a time from the time that this entered until it leaves whether it's a set time or a time from the time that it entered. That's one, but the rolling expiration is interesting too. That's more like session

type stuff. Like if you log into a website, right? It might say that you're alive for 10 minutes. Like your bank is a perfect example. If you log into your banking application, so you can look at your checking account or pay some bills or whatever. Typically there might be a five minute timeout type thing. And as long as you do something in there that causes some sort of server action, it's going to say, Hey, this guy's active in here and now let me refresh it. So he has five more minutes to mess around. Well, it also kind of plays in with the least used, uh, caching principle too, that, um, you know, you, you cash that item and let's say you say that this item is good for five minutes. And then if it's used again within that five minutes,

then you add another five minutes onto the timer. And then each time it's used, you keep doing that as you suggested, right? But if it's never used during that five minutes, then maybe it wasn't that valuable to have cached anyway so it's safe to get rid of right right um and and maybe like you know i know we're talking about saying in five minute increments just to make it an easy number but what if it was something larger right you know like an hour right or something yeah you want the stale stuff to disappear right um the next part is stuff that I thought was really cool in the.net core

caching stuff. Uh, there are ways to where you can check on dependencies and you can define these things. So you can have a key dependency. So let's say that you have, um, multiple keys. Like we were talking about the key value pairs. You can have one based off another one. So if, if my user ID is based off of, I don't know, a maintenance key, like, let's say that you had a maintenance key in your cache that said that, okay, right now there is no maintenance going on. But then you set that cache to say, yeah, there is maintenance going on right now, then maybe invalidate your user ID for right now, it's going to log you out and say, hey, you can't do anything right now, because the server is in maintenance mode, right? So you can use one key to invalidate some other ones. Go ahead. That's actually, but that's not a concept

new to the ASP.NET core. Does it exist in the old one too? i mean like i keep bringing this one up and i'll do it again the http runtime uh cache property which again there's a similar um you know the object cache class that's in the system dot uh something whatever um where is that one system dot runtime dot caching uh that's meant for desktop applications they have the this concept of the dependencies there as well so let's say for example you know going back to your user example so there's a user object that you might have cached and then you might have all of that user's payment instruments also cached as separate objects. And those payments, you know, by payment instrument, I mean, like, you know, a visa or an Amex or whatever. So so let's think this is an e commerce site, or application. And so you get that query for the user object. And

then you also eventually end up querying data to get the their payment instruments and you can set the payment instruments to be dependent uh to the dependence as dependencies of the user so if the user gets cat um i'm sorry the user gets evicted if that gets cleared from the cache for some reason then those other ones ones would as well. And that's part of that runtime.cache property. Yeah, that's cool. And then you've got also file dependency type thing. So you could literally have a cache item dependent on a file on the disk. So if that thing changes, then it'll clear the other ones from the cache. SQL Server and.NET obviously has close ties. This looks like it was available from 2005 and above. So hopefully you're at least running on

that if this is a thing for you. So you can actually tie it to a table. Apparently they also introduced changes to rows at some point. So those are ones, there's an aggregate dependency. So this item could depend on multiple items in the cache. So go into your user payment thing, right? Like there might also be, um, your payment instrument might be based on your user object and then the user address or something like that. So if either one of those things change, then it could kick it out. Uh, and then there's also a custom dependency. You can create your own. What do you want this thing to be based on? Which I think, I mean, it gives you a ton of flexibility, right? Like, and it just adds to the whole notion

that caching is complex. There's a lot of different ways that you might need to look at this to figure out what's the best way to clear these things out. Yeah, I got curious. So I went back and checked on it to see how in the, going back to that HTTP runtime.cache property, which is using an instance of the system.web.caching cache class, there's a, in the insert insert method one of the overloads for the insert method is you can specify a cache dependency object that you know is like what you said exactly like what you said you know aggregate cache dependency inherits from it as well as SQL cache dependency inherits from it.

But, you know, that's where you can define that relationship. Very cool. Joe, you want to hit us on the last one that we got here? Yeah, sure. I was just thinking about custom caching. I was trying to imagine like a scenario where I would write a custom one, like don't cache on Tuesday or something, but I'm having a hard time with it. Just don't cache at all because it's hard and it's complicated

and you're going to get blamed for everything. Right. Yeah. Who cares about the speed? So notification of cache item removal. Basically, you can hook in some sort of event that lets you know when a cache item has been removed, which could be useful.

I don't have a real good use case i can think of here as well although it might be kind of nice to have like a say alert sent um if you see a lot of cache items being removed because that would be an example of um you know maybe something funky going on so that's interesting to know um but other than that um i can actually think of some that i've done so So, well, for one, just from like a logging and debug perspective, it can be nice to know when something gets removed from the cache. Because, again, remember I said that caching was complicated and you shouldn't do it because you are going to get blamed for it, right?

And so, inevitably, when you do get blamed for it, it's nice if you already have that call back in there so that you can see when it was removed so that you can, you know, when you're trying to debug this thing, it's like, oh yeah, here's where it was inserted, here's where it was removed. But then if you were also doing any kind of, like maybe you have some, how to describe this, some, let's say, class, you know, some object that's kind of sitting on top of that built-in cache, right? And so based off of when things are happening in the cache, in.NET's, you know, cache, then maybe you want to take action on it and so um you know that's when you can have that call back you know able to call back into your object so that you can you know do whatever you need i'm doing a

horrible job of describing that but you know what never mind just forget it don't use it it's hard so actually jason from our slight chat had brought something up along these lines prior to us even starting these episodes. And he had a situation where he needed to cash a certain number of pages on an e-commerce site nightly. This is kind of a decent thing for that. So you could have a callback to where maybe you boot something from the cash and you have it auto re-add it to the cash every night. So it would, you know, a callback could literally be, okay, let's put this right back in. We didn't want this thing to exit the cache. This needs to go in immediately because this always needs to be available, right?

Because this thing might take 30 seconds otherwise, or two minutes, or five minutes, or whatever the case may be. So that's actually a case to where you could have something like that. You have a callback that literally solve that differently though. But well, you could, you could. Okay.

Okay. So, cause, cause immediately when I was thinking about that, as you were describing it, I'm like, well, why wouldn't you just set the expiration to be like way out into the

future? But if in the case, let's say hypothetically that this had, um, you know, not static, not completely static data, but had, you know, not static, not completely static data, but something, you know, where it changed frequently enough, and maybe midnight, I think was the example you gave,

maybe that's enough, you know, like it changes once a day, then, okay, yeah, in that example, I could see where you could use the callback method as a way to like, you know, re-trigger whatever action is necessary to cause it to get recached. Well, let's talk about a new instance of it to be recached. Well, let's talk about the scavenging too. So you want this to happen every night at midnight. Great, right? You could even schedule something for that. But let's say during the day something happened and it got booted because of some memory pressure. You need that thing back in the cache now see that's the that that's where i feel like you're going to get it could be dangerous because of the thrashing right like you don't know why it got this is where

you're going to create trouble for yourself so maybe maybe but it's hard to say but if it's one of those things that you know needs to be in there having that callback could be a way to do it there could be other reasons but i just thought that that might be one way to where you could say hey i'm just going to clear the cash at midnight of all these things and i'll have it go back in and do it right i mean for most purposes i would kind of lean towards not bothering to cash something until it's you know actually been requested at least the first time but because like in this case like what you're describing you know if it got booted in the middle of the day because it needed to be and then and then not because of um a memory problem well well not big not because someone actually requested it but just because someone coded it

you know uh five weeks ago that it should just automatically you know pop itself back into the cache and then it's going to get into this recursive problem where you know it's going to put itself back in the cache and now it's going to get rid of something else in the cache it was older until eventually it's going to cycle back out again i don't know i feel like that's kind of a dangerous way to do it yeah i don't know i guess it depends on your use case though or if you just have a ridiculous amount of memory and you don't have to worry about it. Well, and the other thing that you got to remember, too,

is like with e-commerce, like there's other things coming to play. Like if Google indexes your site and your pages are super slow, you get bumped down in their results, right? So it might be something to where you're doing this just so that you know that the crawler comes along. It's not going to see that your page

took 30 seconds to load, right? So it might be one of those things that you know that the crawler comes along, it's not going to see that your page took 30 seconds to load, right? So it might be one of those things that you do need in there. I mean, there's all kinds of different situations. I mean, you don't know. Yeah. Yeah. I mean, specific to Google, though, you don't know what time they're coming. So you want to have it.

When they do come, they're only going to allot a certain amount of time. So they're going to try to crawl as much as they can in a you know in a period of time before they just have to move on because then it's too big and so if it's your most important pages you want to make sure those things are available so you might not want to do it for every page on your site but if it's like we talked about earlier if you have the 10 most important pages have a whole conversation on seo oh you could now totally i mean we could go on for hours about that alone, but I don't know, like the use case could definitely, but that whole idea of having

a callback to where you can do something, if it exits, that's amazing, right? Like, because you now can act on something immediately. So I don't know. I thought that was really neat. Use that one carefully. Well, at least know your use case, right? And know exactly why you're doing it. All right. So let's go ahead and discuss the resources we like because there are a few. Well, I feel like a lot of these, let's see, there is the the item how to say this the Scott what was his name Scott Allen wrote a that how to use the HTTP context items collection

that I referenced earlier so we'll have a link to his site but I just love his domain so I have to say theodecode.com, and we'll include a link to that. Yeah, we've also got four links here that we'll have in the show notes for things specific to ASP.NET. So if you're interested in reading more about the caching, removal notifications, core distributed cache, or core caching, then we've got the links for you yeah

and again these are concepts that are familiar for basically every platform out there so um on to that our tip of the episodes no it's it's totally the tip of the week this is alan's favorite section tip of the week yeah we've been doing good lately. Yeah, this is every two weeks for a month. I mean, whatever week you were listening to this, it's the tip of that week. Tip of that moment. Maybe that's what we should call this. No. All right, anyways.

All right, Joe, what'd you get? All right, I'm stealing this one from Mr. Automation, who you might remember from our reviews up above. Yay! He's also a member of our Slack channel channel and he sent me a really awesome tool. It's Void Tools. Well, that's not the name of the tool. I think the tool is named Void Tool. But I'm going to double check that right now.

It's called the Everything Search Engine. Sorry about that. And what it is, is a really freaking fast search for a computer. And if you've ever looked for something on your C drive, then you know how miserable that can be. And I don't know why.

But this does a great job at somehow indexing your computer. I think it might even run as a service. I'm not really sure how it runs in the background, but it's free and it's freaking fast. And so no more waiting for 10 minutes, going to the bathroom, getting a drink, coming back and seeing if it found your Dropbox.exe.

True story. And so you should download this tool. I used to use Agent Ransack for stuff like this, and I still probably will continue to use Agent Ransack because it's got a lot of really options, and I like the interface for doing like Regex searches and stuff. But Agent Ransack builds its indexes as it's searching. So it gets fast for repeated use,

but this seems to kind of do that in the background. So it's just really fast for searching for stuff. And I really like it. So everything is searching for tools. I guess you really have to lose stuff on your local system a lot though. You know, Google used to have a Google desktop. I don't remember what it was called. It might been called google desktop agent i don't know do you remember

that though i do remember it and i think i installed it and uninstalled it like quickly yeah i mean because it did the same kind of thing but you really have to lose stuff a lot locally which i guess is a problem for joe so oh no man this is something that you know 20 years ago people would have said, why do I need to search my email? Don't you organize it? But it's a life changer. You don't understand how fast this thing is.

I'm typing in Dropbox right now, and it does it by letter. So as soon as I type the D, I'm looking at every file on my C drive that has the letter D in it. D-R-O. I've already found it, but it's instant it's fantastic okay that's cool i'll be checking it out so why organize things when you can just search for them i agree that's why i don't organize anything zero inbox is a myth all right false um you know i was gonna say that it was episode 43 but maybe it was uh 44 let me let me get this real quick let me just double check it was uh yeah it was episode 44 so um you know how like

i've been called out once or twice for uh you know having to like fact check you guys you know right like that maybe have said been said right and it's like oh why does michael doubt them so much and it's not like i'm trying to be a jerk or anything you know it's just like you know it's more like just excitement like oh wow really no way and and you know of course i gotta go check something out so alan made this claim in episode 44 that um all of this talk about bash on windows was actually going to be amazing and that uh i should take a listen to the show the ms dev show did with uh uh, what was his name? Richard Turner. And, uh,

you know, give this a listen to and see what I thought about it. And I gotta say on, I was wrong. You were right. The internet just heard that. That just happened. You know,

listening to this guy, it was amazing. And, uh, so, you know, I mean, this guy, like I even mentioned it during episode 44. This guy's whole job is to make the command line cool again. Like how awesome a title is that, right?

So we'll include a link to that show again, to the MS Dev Show. But I also want to include the instructions, the install guide for the Windows subsystem for Linux, because that is my tip of the week, is update your system so that you can get it, and if you're lucky, depending on your version of Windows and not Enterprise,

then you can use that, and you can have the best version of linux distribution ever which turned out to be a windows distribution which is really weird when you think about it but i know if you haven't already listened to that episode then you're thinking like man this guy is crazy what is he talking about it's amazing just listen to it i really don't know why i feel like microsoft did a disservice when they decided to call it bash on windows because it's really so much more than that it's linux on windows they

they really i don't know why they didn't just flat out call it linux on windows because that's really that that states it better in my opinion when i call it bash when i boom to that's what they should call it on linux yeah and it's called the windows subsystem for linux which is also like only a name that microsoft could come up with right like i feel like there should be like a windows subsystem for linux 2016 professional right like you know doesn't it feel like it should be like that it why not just have a simple name but you know yeah that that's microsoft's uh naming conventions apt get baby and it will work yeah it is absolutely crazy when i listened to that episode i got so excited i was like you know what i i need windows 10 on everything and

immediately uh you know because windows subsystem for for Linux officially came out. I think, I want to say the date was like August 2nd and let me see here. The date was, uh, yes, August 2nd. So you need to make sure that you have the Windows 10 anniversary update, which will be build, uh, 14, three 93. All right. And it needs to be, you know, an X 64 based processor, uh, with be, you know, an x64-based processor with either, you know, an AMD or Intel-compatible CPU, right? And let's see, 64-bit version of Windows is required. Now, here's one thing that was confusing to me, too, is it was saying, like, you know, at the time, you have to be a member of the Windows Insider program. But, you know, it was released on 8.2 so yeah i don't know yeah i mean fact is it's amazing that part but there there's some great videos out there of it there's some uh um you listen to that episode of MSDev show. It's fantastic.

I, unfortunately, have had the misfortune of not being able to get it yet because Enterprise. If you're using Windows 10 Enterprise, then you're not going to be so lucky, unfortunately. Or at least that was my experience. Maybe I'm wrong. Somebody tell me I'm wrong. No, actually, they mentioned it on the MS Dev Show. In one of their episodes, they said that it's not available on Enterprise.

I don't know when it'll be available on Enterprise. Yeah. Which kind of stinks, but, you know. Well, I mean, I would say when something freezes over. But then again, we never thought that Linux would run like this on Windows, and yet here it is. Right, right. Like literally, in the way they actually described it too was exactly as you know what we kind of uh theorized too was that it being like uh you know using like a facade pattern um was i'm trying to remember everything that richard said now but um, yeah, it's cool stuff.

If you're lucky enough to have the anniversary build installed, then you definitely need to take a look. There'll be a link in the show notes for the install guide for the Windows subsystem for Linux, and you too can have your Windows download the Ubuntu ISO too to install linux on your windows system and you have like the best of both worlds there now there were some caveats though because there were some things that they didn't have some interoperability that they don't have working yet this is still considered very much beta um so i'm trying to remember like what an example was where like you couldn't uh kick off

i think like uh you couldn't kick off you couldn't spin off a windows executable from the linux side yep there were also things like docker wasn't really available for it yet like there were a few things that they're working on but they they are constantly working on making yeah they're iterating on it yeah so yeah it's, because the goal is it'll be seamless. Yep. All right, so my tip of the week. This actually came out of a conversation on Slack that was pretty funny. Like I said, man, if you ever want to look cool like those people on CSI or something,

all you have to do is run app get update and app get install something and then just streams of text fly through on Linux. Right. And people are like, wow, this guy knows what he's doing. It, it, it was just funny because I've definitely gotten that look from people before or just tail log, right? Tail log. And there's, there's just streams of text flying everywhere. Well, mad Viking God over on Slack said, no man, when I want to look like i'm doing something cool i go to hacker typer.net just have that open in a window in your browser and push a few keys and as people walk by they're like holy smokes this dude is amazing so this thing's awesome

if you go to hacker typer.net and just start typing a few things, it's just spitting out code nonstop. Okay, wait a minute. Wait a minute. You don't have to push any keys. All you got to do is just push one key and keep it held down. I haven't even tried that yet. Yeah.

It doesn't matter. You can type a bunch of characters just so people hear the clickyy clacky of your keyboard and they think that you're typing but really it doesn't matter what keys you hit because it's only looking for a key down not necessarily the specific key dude it's so yeah no it doesn't matter what key it is you just you just punch buttons and people think that you're just a mad skilled programmer and it's in the monochromatic green on black background so it already looks very geeky and it's it's absolutely amazing and it put a big smile on my face when he told me about it so that is a compliments of mad viking god over on slack so um you know have fun with that put it up on your screen. Impress somebody. You know, get a raise.

Who knows what may come with this? You pretty much want to, you know, anything below your function keys. Don't use the function row or else you're going to get tripped up. And the one key that I've found that actually does what it's supposed to is the delete key. Oh, does it really? Yeah, if you were to like go backspace on it, it goes backspace. Oh, that's awesome. Yeah, man.

I'm thinking of something a little more nefarious and truly hackerish was basically next time the in-laws are in town and it's time to go to dinner or go shopping at the outlet malls. I'd be like, are you kidding me? Do you see what's going on here? I can't go. Look at this. Look how

busy I am. The world is crumbling. I've got subroutines to write, man. It's the Russians. For some reason, I assumed that you were going to describe that you were going to just leave that full screen on your parents' computer and then they press a button

and they're like, oh my god, what did I just do? Why am I writing code suddenly? Oh no, that involves more work for me. I'm usually more interested in getting out of things. Oh, that, that involves more work for me. I'm usually more interested in getting out of things. That's killer. All right, so that wraps up our tips of the week. Yeah.

Yeah, that's pretty much it. So last episode, episode 45, we talked about hardware latency, and we showed how saving copies of your data to faster and closer locations can save you, I mean, just astronomical amounts of time. And in this episode, we focused on a particular web framework and discussed some of the tools and frameworks, some of the tools that frameworks provide you, the programmer. And don't forget that there are also lots of other layers in place, things like ISP, CDNs, browser cache, all sorts of other

things that come into play, but we just wanted to focus on the kinds of things that are available to you in the framework that you're currently working in. And we took a look at caching in ASP.NET. And in future episodes, we're planning on, I feel like we keep saying this, but we're planning on diving into some of the more computer science-y type things and caching, taking a deeper look at some of the algorithms and data structures that we discussed today and looking at some common common strategies uh so things like search engine cdns and also um like very programmer specific techniques like memoization that can make huge differences in performance

and we hope you enjoyed it. So with that, subscribe to us on iTunes, Stitcher, or more using your favorite podcast app. And like we've said before, be sure to leave us a review. You can visit codingblocks.net slash review to find links to Stitcher and iTunes. Yep. And up there, you'll also find our show notes, examples, discussions, and more.

Yep. So send your feedback, questions, and rants to comments at codingblocks.net and follow us on Twitter at codingblocks or head over to codingblocks.net and you'll find social links and really advanced show notes where you can leave really awesome

comments. Indeed. Or not so awesome. I like the advanced show notes. We got Markdown. We do have some Markdown. Check out our advanced show notes.