Runtime Arguments
Conversations about technology between two friends who disagree on plenty, and agree on plenty more.
Runtime Arguments
18: The one where Jim asks Wolf questions
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
This episode is a little different from our normal format.
When you listen to podcasts, watch Youtube videos or even sit in a conference room listening to a speaker, they almost always will mention things and assume you know what they are talking about. And lets face it, we don't always know what they are talking about.
In this episode, Jim asks Wolf questions. Questions about things you hear in other podcasts (maybe even ours) or other places and you don't really understand what they said so, if you are like us, you have to go look up whatever it was they mentioned, just so you can follow along.
It's a fun one and we're sure you'll get something out of it.
And, if you have questions you'd like answered, please send them to us. We'll probably do this again sometime.
Links:
HackerNews: https://news.ycombinator.com/
Advent of Code: https://adventofcode.com/
Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm
Follow us on Mastodon: @RuntimeArguments@hachyderm.io
If you have feedback for us, please send it to feedback@RuntimeArguments.fm
Checkout our webpage at http://RuntimeArguments.fm
Theme music:
Dawn by nuer self, from the album Digital Sky
All right. Well, there's that uh that intro music. Uh Wolf, you know what that means, don't you?
Wolf:Uh I think I do. I think it's time to be terrified.
Jim:Yeah, it's another episode of Runtime Arguments. I'm Jim McQuillan, and here's my buddy Wolf.
Wolf:Hey everybody.
Jim:How you doing, Wolf? Everything good?
Wolf:Everything is good. Do you have a nice little holiday uh the holidays are making me happy um and I like to think about the things I'm grateful for. Um, and I really have a lot to be grateful for. I love my family, which includes my dogs. I have a great team at work. Um, I'm solving interesting problems. I'm using a language I love. Um I have you as a friend. That that is a thing that makes me happy in and of itself. You know? I'm doing pretty good, I feel like. I hope everybody uh is doing good, and I hope that goodness and happiness lasts for them all year long.
Jim:Yeah, good, good.
Wolf:Um, how was your week? Uh it was good. I did have some hardware difficulties. You know, when they came out, I bought these AirPods Pro 3, which for the first time ever, uh AirPods Pro actually fit me. They don't fall out of my ears. They sound everything about them is good. Except I had to reset them from factory style every single time I charged them. And even then they didn't always charge. So finally, I took them into the genius bar uh at Apple. I live very near an Apple store, so it's convenient. And at the Apple store, a genius by the name of Dare, um, I'm not gonna try to spell it, it was complicated, and had an apostrophe. But uh he I didn't just have the AirPods problem. I wasn't connecting my phone successfully to my continuous glucose monitor because I couldn't figure out how to enable critical alerts. And I was also concerned my iPhone's a little older, not that old, but it's the 15 Pro Max, and my battery max capacity is getting down there. Uh so all three of these are problems, and he solved all three. He knew exactly what he was doing, he was uh knowledgeable, kind, smart, helpful, fast. Everything about him was great. Um and although I am normally a kind person, I accidentally was insensitive about his name, which is the very last thing I should be insensitive about, because I have a name that people screw up. Um and even though I was insensitive, he still treated me kindly and with respect and solved all my problems. I tried to make sure that when I got the survey, I said just how great he was. When I went back to pick up the AirPods, I told the people who gave them to me how great he was. Um the guy did a good job. He deserves recognition. That's my week.
Jim:He puts the genius in genius bar, right? He kind of did. How was your week? Uh good. You know, holiday, a lot of family stuff, uh, not so much work, uh, which is nice, you know, back away from the the daily grindstone. But um uh it was really good. Um some projects I'm working on. Um not too much to talk about right now. Uh for a future episode, I've got some cool stuff to talk about though. Um so last uh the last episode, uh episode 17, was about um uh is my key fob more powerful than the computers that put the astronauts on the moon? And it was a really fun episode, and what was what was really great after we did it and we released it, uh it got picked up by Hacker News, and we showed up on the front page uh a week ago Friday, and oh boy, what a roller coaster ride that was. Uh we saw like a hundred X uh downloads of the episode, and that was fun. And one of the neat things is uh it the downloads continue to be more than normal, more than what we were used to. And what we're seeing is some what I call residual effect. All the other episodes are getting downloaded. Uh so I guess new people are coming along, probably for that episode, and then they're discovering some of the other episodes. And we had some really great episodes uh over the past eight months or so. So we're seeing a lot of downloads, and we really like that. Um, we'll we'll take more of that uh any any old day. Um but that episode um where we talked about uh computer power and stuff, um, you know, I've had a couple of couple of weeks to think about it, and and I think I missed an important point in the conclusion where spoiler alert, yeah, your key fob is more powerful than the computers uh that put men on the moon. Um but the the thing I kind of missed is uh you know when you're talking about the performance of a computer, it really boils down to the work that it can do. Uh sure, newer processors are faster and have more memory, but that's just part of the picture. You really have to take into account uh the peripherals and the software and what they actually do. And when it comes to peripherals, uh there's nothing like a Saturn V rocket with five F1 engines uh lifting about 6.2 million pounds of stuff off of the Earth and heading towards the moon. That's that's some serious work being done by those computers. So in that sense, I don't know if there's anything more powerful than the than the the computers on the Saturn V rocket and on the on the Lunar Lander. Uh so just want to put that out there for the record. I think that should go in the conclusion. Um But anyway, uh it was a fun episode. If you haven't heard it yet, go back and listen. It was it was a lot of fun to do. And all of our episodes I think are great. So go back and listen to all of them and tell your friends about all of them, right? Um so today's episode is is different. Uh normally I'll give you a little bit of the uh the the story about how we do these podcasts. Um we do them twice a month, or not twice a month, every two weeks we do an episode. Uh and usually uh we we record them usually on Thursdays. We didn't this week because it's uh Thursday was Christmas. Um so we we have we always create this big outline covering what we want to talk about. And then on Monday, before we record, we go through that outline. We spend some pretty good time going over the outline, making sure we covered all the points we want to cover. Uh any any uh you know we rec we just write down everything.
Wolf:Throwing away.
Jim:What's that? And throwing away. Yeah, yeah. We throw a lot of the outline away to to whittle it down to what we think is the right amount of content uh for the episode. Well, this time we didn't do any of that because this episode is uh really uh uh is I get to ask Wolf questions. Um and the kinds of questions I'm gonna ask him is um are are uh you know when uh you listen to other podcasts or you listen to videos uh uh on YouTube or you attend a conference and the speaker or the podcaster is talking about things that you don't quite understand. They'll use terms that you've heard about a bunch of times, but you don't really know what it means. Um so I thought, wouldn't it be nice to sort of do do an episode where we just give a bunch of these questions to Wolf? Now, Wolf does not know what the questions are because we didn't go over the outline on Monday. Uh, these are questions that I gathered uh by talking to a bunch of our friends who are uh avid podcast listeners, um and they gave me some questions to ask Wolf, things that they've heard before and they don't quite understand. Um and I'll confess, most of these questions I know the answer to, but not all of them. Um and I'm I'm quite sure that Wolf is going to be able to answer these questions. Uh, this is not me trying to stump Wolf, uh, because man, that's just too hard. Uh no about that. I because Wolf is is kind of bright. Uh let's just say that. And um uh so this is just me asking questions that I'm pretty sure he can answer. Uh and if he can't, he's an honest guy, he'll tell you he can't, and then if if we come across a question we can't answer, we'll um we'll we'll we'll cover it in the feedback uh uh on the next episode. Uh so Wolf, are you ready for me to throw some questions at you?
Wolf:Well, uh, you know, I'm I'm I'm a little scared of this whole situation. Um gotta clear my throat. But I just want to make sure people understand uh for a regular episode, I know what we're gonna talk about in advance, and if it's me, I get to do the research and learn everything, and that makes me sound kind of smart. Uh, but now it's gonna be bare metal. There's there's no research. So uh I am not at all confident that I know the answers to these questions. I'm gonna do my best. I'm gonna tell you right away when I don't know. Uh and anything that I don't know, uh, I will look up so that we do know the answers for later.
Jim:Um see. If I ask you a question that I don't know the answer to, and and if you don't know the answer to, but you made something up, I would believe you 100%. But no, you're not gonna do that. You're not gonna do that. Um, so what I want to do, I really have I have 20 questions, and there's absolutely no way we're gonna get through all 20. Uh we might get 10 or 12, I hope. Uh, but what we're gonna do is we're gonna put a time limit on each question of five minutes because some of these questions Wolf can talk a lot about, giving all kinds of great information. So I'm gonna put a limit of five minutes on each question. Some of the questions he'll probably answer in 20 seconds. So uh that does not mean that the next question gets gets all the extra time. We're just gonna put a hard limit of 20 uh five minutes on each question. I'm gonna have a little timer running. Uh, if while he's talking, you hear a uh a beep or whatever kind of noise my my phone emits when the time expires, that's what it is. And then I'll politely ask him to wrap it up. Um so uh are you ready to go? Shall I hit start? Uh actually I'll hit start uh after I asked the question. Okay. Uh here's one that I heard uh not too long ago on a podcast episode. I know the answer to it, but uh I had to look it up a long time ago to really figure out what the answer was. Uh and that is uh what does touring complete mean?
Wolf:Uh touring complete, so there's lots of ways of evaluating systems. Do they meet a specific criteria? Uh big O notation for complexity, for instance. Touring complete is a set of criteria that describe formal systems with which you can uh instruct actions to happen. To be touring complete, you need a couple of things. First of all, it is assumed you are some kind of symbolic system that would be used to instruct a computer. And to be Turing complete, you need to be able to execute conditional logic. So look at some expression, decide if it's true or false, and then if it's one of those, do one thing, and if it's the other, do another thing, and you need to be able to loop. Uh typically you only have to be able to loop forever. Um you don't have to also combine loops with conditions, because it could be that inside the condition you can inside the loop you can test the condition and uh decide to exit the loop. So you only need one kind of loop, and you have to be able to do simple arithmetic. Uh now people will use the phrase blah blah blah is touring complete. And what they mean is, with blah, you can do anything you want. You can figure out the answer to anything. What they don't actually say is, yes, toring complete means you can find the answer. But it doesn't mean it will be easy to find the answer. Um I think I'll stop there. Uh you can absolutely look up the formal rules, but that's what it means.
Jim:Yeah, yeah, it's it's the kind of thing uh uh they the uh the scientists figured out they could, but they they should have thought if they should. Right. All right, all right, let's see. Uh I gotta figure out this timer thing here. Um I'm just gonna do it this way. Um okay, next question. Explain big O notation.
Wolf:Okay. Big O notation, those are the magic words we use to describe the complexity of uh a solution, typically. And sometimes when a problem can only be solved in one way, as far as we know, uh, we sort of can uh conflate that to mean the complexity of the problem. And it's not a measure of the speed of the CPU or what the CPU has to do, it's uh uh more or less a count of the number of distinct operations you have to do to solve a problem. So for instance, if you have an unsorted list of N items, and usually N is a very important uh abbreviation in this world, and they'll use capital N, and you want to find out is five in that list, there's only one way to know, and that way is you have to step through that list and look at each element in the list. It's unsorted. If it was sorted, you could use better better methods. But that means if the list is n items long, you are potentially doing n operations. Um now, it turns out that in reality you'll probably do n over two because you're gonna find it somewhere in the middle uh on average. Uh that doesn't matter. They they round. If it's n over two, it's really n. So the complexity of this uh operation is order n. And the word for that is um that it's linear. Uh there's different numbers that you can stick inside the big O. Like big O1 is a constant time operation. Typically, a hash function is constant time. A lookup in an array is constant time. A lookup in a hash table might involve multiple operations and searching down a list, but it's balanced, so it turns out to be log n and the number of things in the list, or maybe it's not quite as good as log n, maybe it's n log n. But the reality is big O notation is a measure of the complexity of the problem. On a small scale, it almost doesn't matter because complicated algorithms go fast and have real low complexity, but they have a huge constant time, some giant setup. And small algorithms have terrible complexity, uh, you know, like big O, n squared, n cubed, whatever it might be for a bubble sort. But if you only have three items, it turns out that wins because the complexity, the constant time factor, the capital C in the really efficient algorithms was too big and it outweighed the complexity. So that's what big O is. It's a measure of how much work you will do to solve a problem. And what matters is how big is your data.
Jim:Okay, so I see things like uh uh big O uh log N. So that's the that's the the the log of n uh in complexity, uh or big O N squared. Uh that means it's a the larger your data set, the the much worse your your uh uh performance. It's fast.
Wolf:It gets worse fast. Yeah, yeah. So log n good, n squared bad.
Jim:Yeah, n squared or any anything that that becomes exponential uh and it grows very quickly. Right. Okay, cool. Um let me reset this. Okay, next question, and this is related. Um another term I I've heard uh is what is np notation? Uh okay.
Wolf:So the world is divided into two spaces. Um those two spaces are problems that uh we consider to be NP complete and problems that we uh either know or are not NP complete or can't prove that they are NP complete. Um I forget exactly what NP stands for. I think it stands for non-polynomial, as a non-polynomial.
Jim:Excuse me. Non-deterministic polynomial time.
Wolf:Uh but essentially, if your problem is NP complete, that means we don't know any shortcuts. Um the only way we know to be sure we have the best possible answer is some really, really hard, uh, exhaustive search. And problems that aren't NP complete typically are easy. And this is like a mecca in the computer science world. If you can, a thing that we do all the time is we take one problem and we figure out how to pretend it's a different problem, how to cast it in the light of a different problem. If we can find a problem that we know is NP complete, but we can somehow rephrase that problem in a way that we know is not NP complete, and we can use shortcuts and we can solve it without an exhaustive search, that is an aha moment that is. Going to change the world.
Jim:Ah, okay. Aha. All right. Ready for number four? You and I talked about this just recently. CICD. Continuous integration, continuous deployment. Who does that? And why? Do you do that?
Wolf:Okay. Who does continuous integration and continuous deployment? For 10 years, well, for eight years, I worked for a company called Learning A to Z. And uh that was a company that taught kids how to read. Uh, a great mission, a mission that made me want to go into work every day. And the way they delivered their product was it's a website. Um and they were constantly pushing their web changes to the live server. They didn't make changes in production. They tested them all. Everything was good. I'm not telling you they did a bad thing. What I'm saying is when they had stuff that worked, they pushed it to the server, the real server. That is continuous deployment. They didn't uh, you know, push a production build once a month or once a year or once a quarter. They pushed it when it was ready. That's continuous deployment. So continuous, there's continuous testing, continuous integration, and continuous deployment. The first two are a little fuzzy. Deployment, I think there's an obvious boundary. There's where it's not in customers' hands, and then there's where it is in customers' hands. And the difference between those two is the D deployment. And if you keep giving it to them over and over, that's continuous. So do people do it? Yes. Am I doing it right now? No. Um. But it's useful, it requires discipline, it's a way to do development, um, and there are good things about it. Does that answer the question?
Jim:Uh yeah, part of it, but let's talk a minute about uh continuous integration. What I think of with that is what I, you know, years ago you worked at Mozilla, uh, late 90s, right? And I came out and visited you once, and you showed us the um, I don't know what you called it, the test farm or the server farm or whatever it was, where you where anytime anybody checked in something, it was constantly being rebuilt. And remember the tinder box. Tinder box, yeah. That's it. And the and the thing was don't break the build. Um because that because bad things happen. Was that continuous integration? It was.
Wolf:Uh let me for everybody here. This was uh, you know, almost 30 years ago, 25 years ago. And uh the system we had was we had a large number of build machines, a different OS on every single one of them. There maybe were 12 or 15. I don't think there were as many as 20, but there were definitely at least a dozen. Um, and so typical OSs were um, I think we had a Spark station, I know we had HPUX, um there were tons of things. Uh and we also had a web page that was a scrolling table. Each one of those build machines was a column in that table. And when that build machine was ready, uh it would pull the very latest version of the source as of that moment, and there would be a bar, and up until the next time it pulled was one big box in that column. And that box was um, I think it might have been uh uncolored during the time that it was pulling and building, unless there were errors. If uh it couldn't build, it turned red. If it couldn't pass the tests, which included performance tests, it wasn't allowed to get slower, it turned yellow. If everything went perfect, it was green. If at any point that page for the current and you know, rows, the y-axis was time, uh, and it scrolled so that the latest time was at the top of the page. If at any point one of those columns turned red, we now have a new priority. The priority is not fixing bugs, it's not making the program faster, it's not getting your feature in, it is turning that box not red. Make it be green or maybe white. That's job one. No commits to the source code control system at all from anybody except in service of fixing that box. So that was that was continuous integration.
Jim:That was real continuous, constantly integrating the latest changes and compiling and testing and making sure you don't break the build. So cool. Right. So as for deployment, I you know, the system I work on, I think the system you work on, when when we make changes, we we try to do a uh a release maybe once a month. Uh but there's training that goes, there's testing that goes with that, user testing, uh user acceptance testing. Uh there's training that has to be done so that when we do deploy that release, it's a very controlled thing. So certainly we can't do continuous deployment. But I can see your learning A to Z example. Uh that's a good example because you weren't training people how to use that, right? You were just maybe adding features, fixing bugs. And it the newest thing was just out there. Probably like Facebook, I would I could imagine is like that. There's nobody gets trained to use Facebook, right?
Wolf:This is true. However, uh, there's a couple things I want to say. Uh Facebook is big enough and has a lot of incredible engineers. They do uh something which is colloquially known as A-B testing. What they can do is they can release a feature that works in two different ways, and they can arrange for some fraction of the total user population to get one way, and some other fraction to get the other way, and maybe 80% of the population doesn't get either. And they can see what happens with the A's and the B's, and then they can pick. Um and the other thing I wanted to say is that um it doesn't have to be all or nothing. You can uh do continuous deployment on some kinds of things, uh especially critical fixes and things like that, but have big features, brand new UI things, stuff like that, come out at more regular space to part intervals. So it it is a continuum that you're on somewhere.
Jim:Okay, good. That's uh that's the first four questions. How do you think we're doing so far? I'm not stumping you yet, am I? I don't want to stump you. I know you can answer these things. I'm feeling okay. Let's let's keep going. Okay. Uh here's my next question. Um what's the difference between unit testing and integration testing?
Wolf:Uh the size, basically. Uh a unit test is usually something you can hold in your hand. Maybe I've written a function that um decides are you connected to no, that's too big. Let me let me say something smaller. Uh you have a table that you that you've gotten from some system like pandas or nump, who knows what. And your function that you use wants to find everything in the table that um doesn't have a related uh author name in it, and maybe author name's a column. And so you're gonna run your function that you wrote that is gonna actually do some table-based operation. Um a unit test looks at that function, it knows what the API of that function is, and it knows what the result ought to be, um, or it can make up its own table where it is sure to know what the answer ought to be. A unit tests that one function. Does the API work right? Does the function give you the answer you wanted? An important thing to know is a unit test doesn't want to look inside your function. It absolutely should not test how you found the answer. Only that you found the answer. Because if you look inside It's a black box kind of thing. It is a black box. If you look inside, you know too much, and your tests will have to change when somebody decides there's a better way to write this. Integration testing is bigger than a single function. Integration testing happens when, for instance, what in unit testing, if you need something that you can't have because it's too big, because for instance, like your table comes from the database. Well, being connected to a database requires a database, and it requires the database library, and it requires a network, and it requires credentials, and it it's way bigger than a function. But if you want to test those things, which you do, you're going to want a test that knows those things. What database am I using? What are my credentials? Do I have a connection? That's a bigger test. That's an integration test. Integration tests are slower, they're harder to write, they're harder to get right. If you do all your unit testing appropriately, integration testing won't make as big a difference, but it does make a difference. You do want to do it. It's an important part of the test landscape. That's the difference.
Jim:Alright, I'll confess I uh I'm not good at testing. I need to you know, I need to add tests uh to my code. I sort of didn't come up that way, and I realize I should. And there's what what do you say? The the the best time to do it is 20 years ago. The second best time to do it is right now. Uh so yeah, I'm I'm trying to move forward with testing.
Wolf:Uh testing is one of those, before you go on, testing is one of those things that you don't understand how great it is until you actually do it. Um I can name a couple other examples of this. You know, when I was nine, I didn't care about um dating or uh the opposite sex. When I was twenty five, I thought that if you tuned into a TV station and watched a show and got to see it, that was great. I didn't know what a TiVo was or what what DVRs were. Then when I learned about those things, um I was both much happier and much less happy, but I knew what I needed.
Jim:You know, I do have a file that contains a bunch of small functions, utility functions that we use all the time. And a couple years ago I did write tests for that. And it floored me how many of those tests failed. You know, I mean these are routines that are fairly simple, but I was really surprised how uh how how buggy some of those routines were. So it it opened my eyes for testing. Uh the problem is I'm sort of moving at about 100 miles an hour, and to stop and write the test is kind of difficult for me, although I realize I do need to.
Wolf:Everybody says tests slow them down, uh but it turns out in practice, um writing it, writing the tests, and making sure the tests pass turns out to be faster than writing it the first time, finding out it doesn't work, and then writing it the second time. Uh now go on with the next question.
Jim:There's the old thing about how how can you afford to how can you not afford to write it write it correctly the first time, but you can afford to rewrite it later. Right? Uh okay, here's another question. This this kind of I'm sure it it fits right in with this. Um, you know, I uh I listened to the two's compliment podcast. You've listened to it. As do I. I do those guys. And those guys, uh uh uh Ben Rady and Matt Godbolt, they're they're they're geniuses. And uh I was listening to an episode a couple of weeks ago, and they mentioned they they talk a lot about testing. They mentioned generative testing. Do you know what that is? I'd never heard of it before.
Wolf:Okay. Um I'm gonna admit right off the bat that I don't know for a fact what generative testing is, but I do have a guess. I'll give you my guess and then I'll look it up and make sure we know it for next time. My guess is that uh in normal tests, you know what you're testing and what the right answer ought to be, and that in generative testing, I guess there's two possibilities. One is it generates data for you to test, and the other possibility is you have the data and it generates tests. It's almost certainly one of those, and I don't know which one, but I'll find out.
Jim:I did look it up, and and so I'll just sort of read the description I got from Wikipedia, and that is uh generative testing is the same as property testing or quick check testing introduced and popularized by the Haskell Library quick check. Does that help you? Does that work for you? All right, all right. So we we have that one. We need to uh do a little research, and we will have the answer for you uh at the next uh episode in a couple of weeks. Okay, uh let's see. Uh we're on to number seven now. Uh here's one. I know you're gonna love this one. Uh one of our uh good friends to the podcast asked this based on what he heard during the last episode, and that is what is Advent of Code?
Wolf:Ah. Um Advent of Code is um, and I forget the the guy's first name. His last name is Wessel W-E-S-T-L. It is a series of problems, used to be 25. Uh, this year it was only 12 because oh my god, they're hard. And he has gone to so much trouble. Uh these are programming problems, which are revealed one per day starting at the beginning of December. Each problem has two parts. You can solve them in any language you choose. Um they run on your own machine. There are no performance requirements, but the data he gives you to solve the problem is unique to you as is your answer. He knows what your answer ought to be, and he'll give you the second part of today's problem when you correctly solve the first part. Um, I like these problems. They're at adventivecode.com, all one word. They're fun.
Jim:We'll include the link in the show notes as well.
Wolf:They are a great um way to learn more about programming, not just by trying things yourself, but by seeing other people's answers. And as we have probably mentioned before, you and I are on the board of a uh Linux Unix users group called MUG, the Michigan Unix Users Group, and uh once a year we do a meeting where the topic is everybody who wants to participate at the meeting, their solution to a particular day of advent of code, so that we can just see all the different approaches people took. Um I think these are great practice. First of all, um anything that you want to be good at, you there's only one way to get there, and that's to practice. Here's a way to practice. And it's not just a way, it's a fun way. Uh the guy who put them together is generous and smart uh and clever, and the problems are fun. That is Advent of Code.
Jim:Yeah, we've uh as Wolf mentioned, we do this uh for MUG usually around February or or March. Uh I think this coming up will be the third time we've done this, and it's a lot of fun because we get solutions in all kinds of languages that surprise us. Uh, people, you know, everybody's got a different way of looking at a problem, understanding a problem, and then solving it. So we get people that will solve uh that particular problem in bash. Uh I solved it last year in um uh Vim Script, the the programming language inside of Vim. Um, I think you did it in Rust. Uh we had somebody do it in Python. Um, somebody I also did it in Racket. Yeah, you did it in Racket. Uh, we had a lot of fun. So uh there'll usually be maybe eight s eight people contributing to this uh uh meeting uh showing us how they did it. It's a lot of fun. So I I advise you uh check out mug.org uh and and we'll uh put an announcement out there for uh February or March for when we do that. Um anyway, it's a lot of fun. And we'll include a link to the uh Advent of Code website in the show notes. All right, uh let's see okay, here's one for you. Um what does it mean to salt a password?
Wolf:Okay. Um I love crypto questions. Um computers are fast. And uh passwords, when you're allowed to pick them yourself, uh usually what's the name of the word? Suck. Um they're way too simple. There's some super common ones, and usually Usually the algorithms for if you did everything right, uh, you didn't store like you're the website, you didn't store the plaintext of the password, you hashed it and said, and stuff like that. It doesn't matter, hashes are fast, uh, typically. Um, so it turns out that if uh you want to, and you're a bad guy, you can build a table where you have taken uh hundreds of thousands or maybe millions of super common passwords using the hash that um uh you know is gonna be used in this website. And you can build the table in advance. Um it's easy for you to grab the hash by watching the network traffic, uh, even though you don't get to see the password itself, and then just look in your table and get the password out. It's an order one lookup. Um and as you know from our previous discussion, that means it was almost free. So uh that's bad. We don't like that. Uh these tables have various names uh depending on their exact capabilities. One you may have heard of is Rainbow Tables. Uh in any case, hashing the password means that you don't just take their password, you also salting the password. You also tack on extra stuff. Um extra stuff that is not going to be in the pre-calculated attacker table. That salt is known to you, but it takes a table that would work on any password and means it only works in the specific case where they know the salt. Um so it's a way of improving security. Should you be making up your own passwords that might be in such a table? No. Should you be using passwords at all? No. Should you be using uh pass keys? Uh I think you probably should. Anyway, that's my answer to that question.
Jim:All right, thank you. Okay, next. Um I've been hearing this a lot lately. For for years I've been hearing this, but what does zero-day vulnerability mean?
Wolf:A zero-day vulnerability is something that turns out to be wrong with your program that provides uh what they call a vector for attack. Um there's lots of words you could use. You could say avenue, but an a way in. Uh, some problem that gives attackers a way in, and it's called a zero day because everybody knows about it immediately. Something happened, and they have the ability to get in using that hole right now. Zero days are a bad thing. Um a uh uh a particular attack might be known to a researcher before it becomes known to anyone else, but when they reveal it, suddenly it is a zero day. Suddenly everyone sees the uh if the manufacturer, if the people who are we're uh we're trying to protect in this case, if they haven't already addressed it, and usually um honorable researchers give them the opportunity, some amount of time, maybe even too much. Uh but if they don't do anything and the researcher says, Well, look, you didn't do anything, I'm just gonna reveal it before anybody else does, that'll make you do it. Now it's a zero day.
Jim:So that's like uh an embargo period, right? Where the they they know about the problem, they tell the vendors, uh, here's the problem, fix it. We'll give you 14 days or whatever. Uh yeah.
Wolf:I mean, usually they give them like 90 days or something. But that is exactly what it is, yes.
Jim:Yeah. Meanwhile, somebody could uh talk about this uh uh vulnerability and it becomes a zero day and people can hack it before the vendors have had a chance to fix it. And fixing it usually means deploying new software someplace, right? Whether it's a web service or a or or anything.
Wolf:And and the the other side of that, which is not only does the vendor have to fix it and make that fix available, but the user has to say, oh, there's something new, I better install that, huh? Yeah, that's where things break down, right?
Jim:Yeah. All right, next problem. Okay, next problem. Here's one. I know you're gonna love this one. Uh, what is Bayes' theorem?
Wolf:Oh my god.
Jim:And I'm I'm asking this because I know we're gonna do an episode on this sometime uh soon. Uh so this is kind of a little uh preview of an episode coming. Uh so what is it?
Wolf:There are algorithms in this world that are just fundamental to everything, to how the world works. Uh, the way we make progress in this world is the scientific method. Um, we have an idea of how stuff works. Um, we're not a hundred percent sure that idea is right. So, if you're using the scientific method, you figure out how could I prove I'm actually wrong? Uh what do I have to do to show this isn't true? And then you perform that experience, that experiment, and you learn new stuff, and maybe it proves you're wrong, or or maybe it doesn't, and you think of other ways you might be wrong. But you take that knowledge and you adjust what you know right now. Bayes' rule is something that's been around for centuries and something that has been argued for centuries. I am gonna interject one thing in just a second that freaks me out, but Bayes' rule is the formalization of the scientific method and everything else. And that is um you know stuff. Bayes calls those priors. Um, for instance, you have a pretty good idea before you flip a penny that the possibilities that could come out of flipping the penny are roughly half that it'll be heads, and roughly half that it'll be tails. And then you perform some experiments, maybe you flip it a thousand times, and you learn new data. Maybe it comes up heads a thousand times in a row, no tails, ever. And there's information in there for you to learn, and you adjust what you know right now. That's Babe's rule. All Babe's rule says is you see something, you incorporate it into your model, and now you make better decisions. Um There were people who thought this was bullshit for centuries. They were so against it that um they actually killed people for believing in Bay's rule. When we first uh got the capability of nuclear weapons, um, we had these ideas. What's the possibility that we might have a dangerous nuclear accident with these weapons? And the people who don't believe in Bayes said, Well, it's never happened before, therefore it's not going to happen. Um This is the thing I'm interjecting. I can't imagine being so dumb that I would say that. Because I look around and I see all kinds of things. I see cars and I see schools and I see adults, um adult human beings. And I think to myself, there was a time when we didn't have a school or a car, and that person wasn't born yet. And yet, here they are. They never happened before, and now they have happened. Obviously, these idiots who thought we weren't gonna have a nuclear accident were 100% wrong, and also it wasn't very long before we found out they were wrong, uh, in the hardest possible way. Now, Bayes applies to all kinds of things. For instance, let's say you have an airplane, um, and that airplane happens to have three nuclear bombs on it, and it crashes. And they went into the ocean, and you want to know where they went. This is a problem for Bayes. You divide the ocean up into grid squares, and you start searching. Lots of things about where the airplane was flying, their last report, the weather conditions, those are all part of your priors. They tell you things about where might be a higher probability to look. And as you go on, things that you see also inform you. For instance, if you do a very thorough search of grid square a7 and you don't find it, that tells you, um, probably not in A7. And also the old probability for being in A6, um, it's higher now. That's what Bayes tells you. Um, just like when you look for your socks and they're not in the bathroom, well, maybe they're in the laundry room. That's Bayes' rule. As software engineers, we use Bayes' thinking all the time. We don't do the math, but we think to ourselves, well, what would make this happen? It's a bug. Why did it behave this way? And then when you prove it didn't do it because of this, that means it's more likely that it did it because of that. Um, Bayes' rule is fundamental to how we understand things. In fact, uh that guy, Silverman, or is that his name, uh, the one with 538 who did such an amazing job predicting the outcomes of the elections, he used Bayes' rule. Um, it's it it is a great way to understand the world better, and it's not just about understanding the world better, it's about understanding understanding. And that's the answer to that question.
Jim:All right, thank you. Reset the timer. We we went about 30 seconds over on that one, but you were on a roll. I had to let it go. Sorry, I was excited. All right, so uh you've you've been involved in the web for a long, long time, since the beginning, pretty much, right? Um but uh this question came from uh one of our friends. What is the dark web?
Wolf:Okay. Um let me first do it by analogy. In any big city, there's the places that you normally go, like the hotel you're visiting and the famous market that has all the things you care about. And then there's places that you know not to go. Like, um there is a place in Switzerland called Needle Park. That's not its real name, but that's what they call it. And the reason to go to Needle Park is because you want heroin. Um so you don't normally go there unless you want heroin. I've never been. I've never been either. Not um I don't think I have. Anyway, um, certainly I don't want heroin. Anyway, um the dark web is a bad place. It is websites that there aren't normal access routes to. They're not listed in your search browser, but you can figure out how to get to them, and when you get there, you can use them to get stuff that normally you wouldn't be able to get, either because of law, regulation, uh common sense, whatever. Often you have to buy these things with cryptocurrency uh because that's its killer app. The dark web, it's the bad places in the big city uh that have the stuff you probably don't want or need, but someone wants it and they're spending money to get it.
Jim:So you you you don't get there with Firefox, right? Yeah.
Wolf:Well, actually, you can. Uh you just don't get there with Google.
Jim:Okay. Okay. You just you gotta know where to go, right? Right. Alright, so uh we're getting near the end here. We've I've got two more questions for you, and then it will come up with a little bit more. Let's do them. Okay, so here's one. I I hear this term all the time, uh especially in databases. What is a tuple? T-U-P-L-E.
Wolf:Okay, so um there's two different ways to pronounce this, and I don't know which is right. There's tuple and tuple. Um I've heard them both. I I've heard them both. I say tuple. I don't have any reason to say tuple, except that maybe that's the one I heard first. And a tuple uh has different meanings in different languages, but generally what it is is an aggregate data type, so like a structure or an array or a list, um, but typically unnamed variables. So um in Python, for instance, a tuple is exactly like a list, except that it's uh read-only. Once you've made a tuple, you can't switch out an element that's inside it or add new elements on the end. You can use it to build a new tuple that has the elements from the first one or whatever. Um and just like a list in Python, it's uh homogeneous. No, that's not right. Heterogeneous, heterogeneous. So yeah for instance, you could say, hello world, five, true, um, nine, nine nine, and that could be a tuple. Uh typically um there's some uh special magic in a lot of programming languages to automatically deconstruct tuples and assign them. Um in Python normally there's parentheses around a tuple in any case where it might make a difference, but they form automatically if you need to. Uh and because of automatic deconstruction, if I have a pair of variables a and b, I can use automatic tuple construction and deconstruction to swap them. I can say a, comma b equals b, comma a. And what that does is it says, oh, you got commas, both those sides are tuples. You just swap the values. I'm gonna assign the whole tuple at a time, but I'm deconstructing, I'll put B into A and I'll put A into B. So a tuple um is really just one more kind of data structure. It typically doesn't have names for the individual elements. They're usually small, um, like a two-tuple or a three-tuple is a lot. People use them um in languages that don't otherwise allow you to return more complicated answers, to return multiple things at once, like uh the answer and an error message.
Jim:Um like Rust.
Wolf:Uh okay. I'm gonna go with okay for that. Okay. So that is what a tuple is. Let's get on to the next.
Jim:It's typically immutable.
Wolf:Um in Python, it's immutable. Um it's more about just being another kind of aggregate data structure. Okay. In in general, when a mathematician or somebody says it, it just means we're gloming some values together and we're gonna act like they're one thing. Yeah, and I think it's a good thing. But it's not like a point. A point has an X and a Y.
Jim:Yeah, okay. I see it in functional programming. You're you're sort of passing tuples around, returning tuples from one function, passing it to the next, and and they're immutable, and uh, but you use them to create new tuples every step along the way. Okay, good. All right, so that's 12 questions. Uh and you did really well. Uh I've got the the 13th question, and this one might be tough for you. Is wolf really your full legal name?
Wolf:Wolf is really my full and complete legal name. That's all there is. It's the four letters wolf, exactly like the animal. That's how it appears on my birth certificate, on my social security card, on my driver's license, and on my passport. Did my parents give me this name? No, they did not. I chose this name, it's mine. If anybody knows me long enough, knowing how much trouble it is to have one name, they will sooner or later suggest a change. All such changes have been suggested. Long, long before the person in question gets to the point where they are going to suggest something. I don't want to change my name. I like my name. It is what it is, I'm keeping it. That is the answer to that question.
Jim:All right, good, good. I you know, every time we uh we introduce the podcast, I always say, I'm Jim McQuillen, and and here's my buddy Wolf. And now they know. Ha! All right, all right. No more questions, we're out. That was a lot of fun. Well, we're kind of out of time, you know. We're at just about an hour now. Uh, I think we did pretty well. Uh I've got more questions, but you know what? I think if you want, we'll do this again sometime. And uh, you know, not often, but once in a while, we can throw questions at Wolf. Uh, we had some really good ones this time. If um you know if the listener comes up with any questions um you know feedback uh send it to feedback at runtimearguments.fm or talk to us on Mastodon or whatever. We'll include all of the the ways to contact us in the show notes. Um let's see, get back to this old thing. Uh so that's that's kind of our uh uh our our episode. Um I had a lot of fun doing it. Uh uh it didn't require a whole lot of research, just uh you know, ask my friends for questions. Uh and and so there wasn't a whole lot of prep going on. And uh, you know, this being a holiday week, it's kind of nice to take it a little easy. And I think we had fun. I think you did really well. I uh I applaud your ability to answer these questions. And there was the one question that we said we would uh get back to. Um Generative testing. Generative testing. Yeah, we will uh we will provide an answer to that uh in our next episode.
Wolf:So uh and I also if I can, I want to say that um I did my best, but it's almost certain that um I left out information that was important uh and possibly especially important to one uh one or two listeners on a particular question. Um feel free to tell me I screwed it up and fix me. Tell me what was the right answer, uh, and we'll we'll fix the fix the answer.
Jim:Yeah, and once again, uh the way to do that is send us email at feedback at runtimearguments.fm. Uh we would love uh your feedback uh uh on these answers uh or on anything. Uh just let us know. So I think with that, I I think we're all set. Uh you good, Wolf?
Wolf:Uh I'm good. This was a lot of fun, and it didn't turn just like eye surgery, did not turn out to be as scary as I was anticipating. Yeah. I was unhappy about generative testing. I gotta fix that.
Jim:Yeah, well, that's that's what we'll do. We'll fix it. All right. Well, thanks. Uh thanks for being a good sport and uh going along with this. And uh thanks to the listeners for listening, and uh, we'll see you next time.
Wolf:Thanks, everybody.
Jim:Bye bye.
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
CoRecursive: Coding Stories
Adam Gordon Bell - Software Developer
Two's Complement
Ben Rady and Matt Godbolt
Accidental Tech Podcast
Marco Arment, Casey Liss, John Siracusa
Python Bytes
Michael Kennedy and Brian Okken