Transcript #177: Coding is 90% Google searching or is it?

00:00 Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 177 recorded April 8th 2020 I'm Michael Kennedy and I'm Brian Okken and this episode is brought to you by Datadog check them out at Python bytes Fm slash Datadog more on that later Brian. Can you believe that it's April? I really can't it doesn't feel like it I know I feel like we're still kind of in the winter mode and yet it's warm and sunny For the first time in seven months. I've been told yeah - Yeah, well I'm doing yard work, but it was just sort of feel like we're gonna skip Easter.

00:32 I don't know what's going on there.

00:33 - Yeah, it's crazy times, but at least it's warming up out there and that's lovely.

00:38 So before we get into our main items, I have a very exciting announcement that we were just working on to let everyone know about.

00:45 So we're trying to find other ways for people to learn about or consume the podcast, other ways that you can interact with us, you dear listener.

00:54 And so we are launching a YouTube project, to the YouTube channel, so right now if you can, you're up for it, go over to pythonbytes.fm/youtube, click subscribe.

01:04 I honestly don't know if there's gonna be any content there yet, probably, probably maybe, we're not 100% sure because there's none now, but by the time this episode comes out, I think we'll have some.

01:14 And the idea is, each segment that we're covering, we're gonna have a dedicated little video of Brian and me talking, and if there's another guest, that'll probably involve them as well.

01:24 And so it'd be really nice to have that for everyone, I think, to just be able to quickly dive in and watch a video, see the two of us talking here as we see each other, but also be able to just focus in on one topic.

01:39 I'm not quite sure how it's going to service, but we'll put it on the YouTube channel, probably put it on social media, and feedback would be very welcome there.

01:45 - I'm super excited for this.

01:47 It's going to be great.

01:47 - Yeah, absolutely.

01:48 So am I.

01:49 I'm also a little excited for pip and the whole packaging thing around Python.

01:53 Yeah, well, I am too.

01:54 One of the things I'm looking forward to, I think we covered this a couple episodes ago, is the dependency resolver coming in changes in pip, which is exciting.

02:06 But one of the reasons why we're having, I mean, there's been a lot of packaging changes lately.

02:10 We've had relaunch of PyPI in 2018.

02:13 Some security features went in in 2019.

02:16 One of the things I didn't know about was more support for users with disabilities and multiple locales were added in 2019.

02:25 And there's been more security features and the dependency resolver being updated for 2020.

02:31 And a lot of this has to do with some money that came in through some sponsorships and through a gift from the, I think it was Facebook Foundation or something like that.

02:41 But anyway, so money came in, but they were one-time things.

02:44 And the Python Working Group and the Python Software Foundation wanted to keep this going.

02:49 So they're launching an all new sponsorship program help sustain and improve the Python's packaging ecosystem.

02:55 And funds raised through this program will go directly towards improving the tools that all of us and your company uses every day to sustain the continued operation of the Python package index.

03:08 And so I wanted to highlight this because I think it's really important.

03:13 And I depend on PyPI and packaging.

03:16 And I know my company does even more and more and more people are moving towards more Python tools.

03:21 we're linking to this page.

03:23 One of the things on there is there's a prospectus for what you get as a sponsor, and you can apply to be a sponsor there, and there's a link to ask questions as well.

03:34 And then a note there that even if your company doesn't want to sponsor you, individuals can donate money, either sustaining or a one-time thing too.

03:43 Yeah, I think the changes they've made lately have been in the right direction, and I want to have it keep going.

03:48 - Yeah, let's keep it going.

03:49 The changes, the major changes, like the big rewrite of pypi.org happened because there was a grant, I think that one was from Mozilla at the time, but it was, we actually have some money and some folks can put their full energy for several months onto that project.

04:05 And guess what?

04:06 When you do that, you make a ton of progress and stuff gets better.

04:09 And there are so many companies out there whose primary technology stack is running on Python.

04:17 They have billions of dollars of revenue, and they contribute zero back to Python to keep that base that they are built on strong.

04:29 So this is definitely a chance to encourage your employer to make a yearly sponsorship donation or something like that to the PSF.

04:39 They definitely need it now that Python got canceled.

04:41 That means less revenue for them as well.

04:43 So it's more important than even usual.

04:44 - Yeah, and I think it would be even neat.

04:45 I mean, a lot of people think about these, we have the news, there's news of these huge grants and stuff, and those are super nice.

04:52 But if all the companies that use Python, and you know they're hitting PyPI all the time, even just pitched in like a couple thousand dollars a year, even.

05:01 - Yeah, it would be game changing.

05:03 - That'd be great, yeah.

05:04 So, it'd be cool. - Yeah, absolutely.

05:06 So onto another good cause.

05:08 Listeners probably know I'm very passionate about making sure that we address climate change and move to renewable energy, things like that at all of our infrastructure and our content is delivered carbon-free.

05:21 We have like a broader initiative to make sure that we offset any of the resources we might be using and so on.

05:28 So this next project is sort of in that vein and it's called Energy Usage.

05:32 So the idea is it's a Python package that will allow you to measure the environmental impact of computation.

05:39 So, you know, we've had like profilers, like cProfile, and we've had timeit, right?

05:45 So that's basically the idea of this thing, right?

05:48 But instead of asking how much time does it take, you can ask how much energy does it use?

05:54 And what you do is you give it a function, you give it the arguments, and you just say, run this function and figure out how much energy it uses.

06:02 So it sounds silly, but it can measure how much CPU resources say versus disk versus network it's doing and actually figure out how much computation that's taking, right?

06:13 'Cause at the time it just tells you how long it took.

06:15 It doesn't say, well, actually 18% was CPU and it was this high and so on.

06:21 And it takes all sorts of things into account like the loss of energy across the wires, how far you are away, the location that you're in.

06:28 So it'll actually, the report you get is like, this computation took 1.86 watts of energy and using geolocation, we saw you're in Pennsylvania, so that means you got 25% coal, 0.17% oil, 30% natural gas, 42% renewable, and that's how the energy was broken down for this particular run of that function.

06:50 And it's equivalent to, say, you know, like a certain amount of TV watching or driving so far or US household consumption and so on.

06:58 - Interesting. - Interesting, right?

07:00 - Yeah. - So it's just a nice little package that you can point at some code that you're trying to profile and saying how much energy does this use?

07:07 Should I worry about it?

07:08 Should I optimize it?

07:09 I mean, profiling is pretty close to giving you where you should focus your energy.

07:14 But if you want to know, okay, this is most of the computation, but how much does that actually cost in terms of carbon, or just more specifically, it's measuring energy consumption, which is also just something you have to pay for if you have a data center, then it's pretty interesting, I think.

07:29 - Yeah, we could get like maybe a Flake 8 package that would fail your code if it--

07:33 - If it uses too much or something, yeah.

07:35 Yeah, yeah, it's pretty interesting.

07:37 It'll output PDFs.

07:39 You can run it where it doesn't put anything on the screen, but then it will save a report to a file or something like that.

07:45 - Does it include the running of the, I mean, how much energy does it take to run the usage, energy usage?

07:52 - That's very meta, yeah.

07:54 I don't know if it, how much it actually is computationally intensive, but it is worth pointing out, Because of that, it only runs on Linux because of the system CPU inspection parts of it aren't built out to support other operating systems.

08:11 So you have to be on Linux to do this test on your code.

08:13 Anyway, EnergyUsage, people can check that out.

08:16 It's a cool little package.

08:19 Now, before we move on to the next one, let me tell you about Datadog because this episode of Python Bytes is brought to you by Datadog.

08:25 And let me ask you a question.

08:27 Do you have an app in production that is slower than you like, using too much energy maybe.

08:28 Its performance is all over the place.

08:30 Sometimes it's fast or slow.

08:31 But the most important question is, do you know why it's slow?

08:35 With Datadog, you will.

08:36 You can troubleshoot your app's performance with Datadog's end-to-end tracing.

08:40 Use detailed flame graphs to identify bottlenecks and latency in that finicky app of yours.

08:45 So be the hero that got the app back on track at your company.

08:48 Get started today with a free trial at pythonbytes.fm/datadog.

08:52 Cool Datadog t-shirt included.

08:54 - So Brian, this next one that you put on here, I almost covered it a few weeks ago as well, and I was like, yes, this is really interesting, but then I don't know, something else, like there was a shiny object, and it pulled my attention away.

09:07 So yeah, this is a bit of a philosophical one.

09:10 - Yeah, so this is a, we're linking to just a short little article, but I wanted to talk about the topic.

09:16 The article's called "Coding is 90% Google Searching, a Brief Note to Beginners." And there's really not much here, other than saying that, like, I mean, I guess there's three points in trying to learn how to program.

09:28 And a couple of them are good in that just pick one language to start with when you're learning how to program, and of course, pick Python.

09:36 And then start to do a project, like try to do a project.

09:40 Those are great ideas. And then the third point is, anytime you get stuck, Google it. And the point of the article really is, I think, that coding is 90% Google searching anyway, and people don't usually I don't usually tell beginners that.

09:55 I don't think I agree with this.

09:58 I was wondering what you think of this.

10:00 - I don't think I agree with it either.

10:01 But I'm not sure I agree with you yet either.

10:03 So let's talk about it because it is interesting.

10:06 We probably do agree, honestly.

10:07 I think programming, developer career evolution goes through phases and seasons and whatnot.

10:17 I think in the beginning, you're just super lost.

10:19 You just are trying to figure out syntax and whatever.

10:21 And then you feel really good because, oh, I really got this syntax figured out.

10:24 And it turns out that's a minor part of programming.

10:26 Now you got to like tracking down bugs and using libraries.

10:29 You're like, I got to learn what SQLAlchemy is.

10:31 Oh my gosh, what is a migration?

10:33 Okay, Google migration.

10:34 How do I do migrations?

10:35 Well, this isn't working.

10:36 Let me like Google and up at Stack Overflow.

10:39 And in that sort of stage where you've crossed over, like I'm kind of a competent language user of the language, but I'm not really, like the world is actually open and all these libraries and packages are out there, and I have no idea what I'm doing.

10:54 I don't even know what third normal form is, so I better figure that out, because it says I need it in my design for my SQLAlchemy classes, or whatever.

11:00 I think in that season of your career, I kind of agree with this.

11:05 You're just Googling like crazy, and it's okay, because Google is really good, and the resources out there are really good.

11:11 But when I saw this article, I thought, okay, that's a pretty good message to people who are kind of new.

11:17 You hear how horrible it is to do copy and paste coding, coding and yet this person is saying, like they were in, I think a couple of years into their career, they're like, look, I do this a lot and I don't feel like I'm cheating or whatever.

11:31 And yet I don't feel like, if I had to put a number on it, I would say coding is 5% Google searching for me these days.

11:39 Five to 10, depending on what, if it's like something new I'm doing, it's probably 10% to 15.

11:45 But most day-to-day work, it's 5% or less.

11:48 I don't know, how do you feel about that?

11:53 - I definitely agree.

11:55 Like for instance, picking up a new framework or something, I'm going to be looking it up a lot.

11:58 - Right, there's little spikes as you adopt a new thing, but then it really goes back down, right?

12:04 - But I was paying attention, so I was thinking about this the last couple of weeks and paying attention to my coding style.

12:09 And I do, there's probably at least a handful of times during the day where I'm Googling something.

12:15 But it isn't like everything.

12:14 It's definitely more of a 5% thing or less.

12:17 And then I realized that a lot of the things I'm googling is stuff that I've just decided to not memorize.

12:22 Right.

12:23 Like the syntax of weird things.

12:26 I'm pretty sure that I can have a step size in range, the range function, but I don't use it very often.

12:33 What's that again?

12:34 Things like that.

12:35 Like extra stuff.

12:37 And a lot of this stuff, editor support really helps anyway.

12:41 If I already know what I'm doing, the editor can pop up what the syntax is.

12:46 - That's a really good point, because if I was using just pure Emacs or something that had zero autocomplete, I'd be Googling more, for sure.

12:54 But, you know, on PyCharm you hit dot, and like, well, there's three choices, and it tells you the parameters.

13:00 Like, you don't need to Google for that stuff anymore, because you've got the better tooling.

13:03 - Yeah, and there's different stuff, like, so the syntax, I leave to the IDE a lot.

13:09 There's definitely a skill, so one of the things that I kind of missed article is it's not that 90 that Google searching is 90% of coding. It's, there's a big chunk of your skill set is to learn how to Google something effectively. So in coding, like, like the instead of trying to summarize what the error message is, and then googling that, oh, just paste the entire error message in. That's like one trick to do. And so there's a whole bunch of coding, Google tricks to find the information fast, because I don't want it to be 90% of the time. I want something that I kind of think I remember to be able to look that up in just seconds and then go back to coding again. So yeah, I hope it's not 90%. That would be a very slow way to code.

13:55 It would be, but I remember that being the case back in the day and for me it wasn't googling because I think we had, when I was first doing programming, you have to see if you can remember yours, but I was using AltaVista, I'm pretty - I'm pretty sure.

14:08 (laughing)

14:10 Right, like people who are listening who don't know what that is.

14:12 That was a search engine that was nowhere near as good as Google that existed before Google.

14:17 But the things you would end up, there was not Stack Overflow to search from and all those sorts of things.

14:22 And so it was a lot of books and a lot of user groups, not user groups, like Usenet groups, whatever those were called.

14:29 So there was a lot of like reference research stuff in the early days for me as well.

14:34 And I wish there was Google.

14:35 I could have done a lot more effective Google searching.

14:38 But certainly I think that that is a just past stage one of your career.

14:43 This is a reasonable way to see the world.

14:45 But you're right, it's absolutely a skill and the more effective you can be at narrowing in, the better.

14:51 But then I think it actually is, if people are living that life now, like I'm Googling all the time, this just must be like the rest of my life, I'm going to just do this.

14:59 That won't be the way it is.

15:00 - Yeah, I'm thinking back in my memory.

15:03 So when I learned to program, there was no internet.

15:07 Or if there was, I didn't have access to it.

15:10 So early '90s, late '80s, it was books.

15:14 So I had references.

15:16 And still, even through my early career, I had a couple books that I would rely on, because I knew how to look things up quickly.

15:24 So I had, for instance, I had a sticky note right where the printf translator thing.

15:31 So if I knew how to print F and scan F, what those little percent signs were and all that stuff.

15:37 - Yeah, that's a really good point.

15:39 So I remember I had a C++ primer or something like that, and boy, that thing was all tattered, and I used that a lot as well, yeah.

15:48 But it's not that way either.

15:50 It doesn't matter whether it's a book or Google or whatever.

15:53 It's a phase, but it's not all of coding for the rest of your career.

15:57 - Right, and then there's stuff that you just end up remembering that you like, I'm never going to remember this.

16:02 I know I'm going to always have to look this up because there's some block like printf decoders and stuff like that.

16:08 Yeah, exactly.

16:08 But yeah, like the stuff for parsing strings into dates, like that is not, that is always a Google search for me because I'm just, I'm not going to remember all the details there.

16:17 This next one, if I were to set this up, this would definitely be a Google search for me as well.

16:21 So I'm considering it, but luckily I don't have to Google search it because we're covering the show and Chris Moffitt is covering it and wrote it all up for us.

16:29 So Chris Moffett wrote an article, he's been on Talk Python before, and he wrote an article called Using WSL to Build a Python Development Environment on Windows.

16:40 So WSL is Windows Subsystem for Linux.

16:43 And this is interesting to me because I just recently had this experience where I finally broke down and I decided I've been using Parallels on my Mac, and I have a super fast Mac, like a i9 with six cores, So it should be able to run virtual machines just fine.

16:59 And yet still when you're working in Windows, you're working in any of the virtual machines, like even a virtualized macOS, it's still like the scrolling's a little bit off, like the keyboard's tiny bits of late, there's just a little bit where it just doesn't feel good to work there, right?

17:15 You can totally do it, but it's kind of, you can tell it's not a perfect experience.

17:20 So I finally broke down and installed Windows and Bootcamp so I can boot into Windows and have a true native experience, or just keep booting into my macOS and have that.

17:29 And that is a lot nicer.

17:31 But one of the reasons I don't want to go to Windows is I really love the terminal in macOS, way more than even on Linux.

17:38 It's just super nice.

17:41 And some of the tools you have there are like in deployment on Linux machines.

17:45 So you have this sort of closer to production world, but you have a nice OS with like GUI tools and little widgets and whatnot with macOS.

17:54 And I was thinking, it's not really fair to Windows to stick it into this little crummy system.

17:59 So it's nice to have this other option, but I don't want to go there and do development because I don't have this Linux type system, right?

18:06 It's a nice terminal.

18:07 So what Chris talked about is basically how to set up Windows subsystem for Linux, and there's a new version that came out mid last year called WSL2 that is a lot better, especially around file performance and I/O and sharing and crossing over between Windows and Ubuntu or whatever you choose to run.

18:26 - Oh, cool.

18:27 - Do you do this any?

18:28 - So I tried it really early on, and I haven't tried it since WSL2 is out.

18:33 - Yeah, it sounds like it might be worthwhile.

18:34 So if you look at this thing Chris wrote, he talks about, there's like a little motivation on how it runs and whatnot, I'll give people the lowdown, but mostly it's like a step, a guide of how to set up the various things you want.

18:48 So for example, if you want to be able to have a nice terminal on the Windows side, but then that can talk to the Windows subsystem.

18:57 It talks about installing the new Windows terminal, which we already covered recently.

19:02 It talks about getting Ubuntu from the store, how to upgrade old WSL installations to the version two.

19:09 Also, how you can set it up to use Visual Studio Code in Windows that is actually working on the Windows subsystem for Linux.

19:18 So you fire up VS Code and you're doing your work, and then one of the environments you could choose is like a WSL environment that's actually running on an ultra lightweight version of Linux.

19:29 So you know when you get the little terminal and VS Code and you type over there, right?

19:33 It's running Linux commands, but on your machine still.

19:37 Without a VM, I mean, sort of a VM, but not really.

19:39 It's like halfway between Docker and full VMs.

19:42 - This looks nice.

19:43 So what I am usually doing is, I'll have to try this out again, but I agree with you that I like to pretend I don't have Windows.

19:53 But I do, I mean, my day job, I work on a Windows machine.

19:55 - So maybe this is extra helpful for you because you're gonna be there anyway, right?

19:59 - Yeah, but I mean, so I've already worked around most of it so I use Git, so Git for Windows comes with Git Bash command which is, you kind of have both of them.

20:10 You can do Windows stuff and work around in Bash and it sort of feels like a Unix environment.

20:15 - Nice, well, I'm very excited about the possibility just having native feeling, oh my Z shell on Windows.

20:22 - Oh yeah.

20:23 - That's going to be nice.

20:24 - Yeah, well and I hope this is a direction.

20:26 I think it is, that this WSL stuff is just more and more integrated with the rest of Windows.

20:32 - Yeah, the integration's pretty sweet.

20:33 So if you're in WSL, which is effectively like you're in Ubuntu, right?

20:37 You can type explorer on the terminal and it will open up the Windows Explorer in that folder, in the Linux folder, but it'll open up the Windows Explorer, the native file stuff, right, on Windows, and things like that.

20:52 So the integration's pretty sweet now, which is what I was thinking is worthwhile.

20:56 Also, to start up this WSL, it's like one second.

21:00 So it basically feels like starting a sluggish terminal.

21:04 - Oh. (laughs)

21:05 Yeah, it's not bad.

21:06 - Right, then it's up and running, right?

21:07 - Yeah.

21:08 - Anyway, so this is a really cool breakdown of how Chris is working, and the various tools, like the various plugins for VS Code, and how he configured them to make them all work together and stuff.

21:18 So if this workflow sounds interesting and useful to you, check out the article.

21:22 It's got a bunch of details and screenshots on how to do it and it's not really worth going into those.

21:26 But I think it's a cool idea and I just want to give a shout out to WSL2 and doing Python on it.

21:32 - Yeah, very neat.

21:33 - You got a solid one for us, huh?

21:35 - We've kind of kicked this can down the road a few times, but I thought we'd take a crack at it.

21:39 There was an article written by Derek D called A Pythonic Guide to Solid Design Principles.

21:47 Are you familiar with what the solid principles are?

21:51 - Single responsibility, open-close, Liskov substitution in something, and dependency injection.

21:58 (laughing)

22:00 I forgot what the I is.

22:02 I is interface segregation principle.

22:04 There you go, okay.

22:05 - Yeah, so--

22:06 - I had to look on that one, I cheated.

22:07 - I always have to look it up.

22:08 But I was curious, so the article is interesting.

22:12 interesting article. So the idea is taking all these principles and I'm gonna have to go through and spell check these.

22:20 But anyway, I don't even know where these came from. But this idea that if you're doing object-oriented design, you should have solid object-oriented design.

22:29 I don't know if I completely buy it. Actually, I'm pretty sure that I don't. But this article goes in and also talks about, kind of relates each one to the Zen of Python as well.

22:41 and sometimes it's a little bit of a stretch. And then also just really how to apply these principles in programming and coding in Python. I guess I'll just say my take on solid design principles are there are things that are good to know about and there's lots of different design principles to know about and these are some of them and in developing object systems with objects and all Python uses objects whether you think it does or not.

23:10 If you look at some code and it's hard to maintain, or it already is hard to maintain, maybe some of these principles might help refactor so that it's in a better state.

23:22 But blindly following these rules actually, I think, could possibly make your code even worse, is my take on it.

23:30 Yeah, well, I'm a big fan of design patterns, actually.

23:33 I really love the concept of design patterns.

23:35 And one of the things I love about them is is once you start to think of code in design patterns, you can think of trade-offs and higher level building blocks than just functions or here's a class.

23:47 You can think, oh, this is a, you know, this is going to be an interface.

23:51 And so what that means is here's a benefit and here's a drawback and do we want to go down that path, right?

23:55 Or I like that it lets you think in bigger abstractions than just lines of code or functions.

24:01 So I'm a huge fan of that.

24:03 But one problem that I've seen a lot when people adopt design, first when they learn design patterns and they become super passionate, like, oh my gosh, this is so awesome.

24:11 It could be so easy to go, all right, well, these are going into everything.

24:15 Like, every chance I can get to use the visitor pattern, it's going in, and you're like, wait, wait, wait, wait, the visitor pattern is super complicated, and it only solves a cool problem, but it is really not obvious or easy to maintain.

24:28 The problem it solves had better be glaring and massive, or you're just making it worse.

24:33 And so, I don't know, I see this kind of stuff as salt and pepper and paprika, its code is better with it.

24:40 But that doesn't mean it should be ultra doused at it.

24:44 You know what I mean?

24:45 'Cause then it's not better anymore.

24:46 It's all of a sudden like, this is a really cool study and design patterns.

24:51 I have no idea what's going on.

24:52 Like for example, dependency injection.

24:54 Like there's a few places where dependency injection like at certain layers might be cool and you could apply it and it's really neat.

25:00 But if you do it everywhere, you're like, I have no idea what anything is or how any of them get to each other.

25:05 know that this is a complete mess and I need a debugger to even figure out what's happening all the time.

25:13 And that's kind of my feeling about Solid, especially in Python.

25:18 It's definitely my feeling about design patterns.

25:19 What do you think?

25:21 I definitely have to agree.

25:22 One of the things that, well, I think I agree.

25:25 Both design patterns and the idea around Solid, they were really developed for other languages.

25:31 I don't think, they're definitely not the first tools that I reach for, for making Python more maintainable and design better.

25:38 Like for instance, like you mentioned dependency injection.

25:42 This is, as far as I can tell, dependency injection should be used very sparingly in Python.

25:48 And there are great, great ways to, examples, like for instance, in an application where you don't want to depend on a particular database style or database, you can set up the database configuration early on and then pass that to the system.

26:04 But the problems with looking up, if you want to know more about solid and more about design patterns, almost all the examples are going to be not appropriate for Python, because they're going to be like, you know, Java examples or C# examples or something.

26:19 - Right.

26:20 It's static language examples.

26:21 - Yeah.

26:22 - Yeah.

26:23 I also think that they get, the way they get used, they get used in this like overly general, over complicated way.

26:28 So for example, dependency injection.

26:31 I've got something I can maybe have a data access layer and I want to be able to configure the type of database access it uses and I want to be able to configure the logging messages that it can send or whether or not it logs to a file or at all, right?

26:43 You could take that and require everyone to always pass a database core instance to it and always pass a logger thing to it or you could just have the data access layer have defaults and then you override them only if you need to, usually in testing.

26:59 And so you can set them up so you always have to feel the pain of this structure, or you can set them up so you only even know that it exists if you need to look into it and change it.

27:08 And I find a lot of times it gets used in the hard way only.

27:12 But the problem is, there's like a little bit of hard here and a little bit of hard there, then you compose it, it's a little bit more hard, and at the top you're like, we need 20 things to create this class and get it started, and I don't even know what they're for, they've got to be passed way down.

27:24 And like, now we need IOC, now I can't figure out where stuff is coming.

27:28 There's just a lot of layers that it adds on.

27:31 So I don't know, salt I think is my best, like spice.

27:34 - Yeah, and sometimes simple is good.

27:36 Sometimes just a cookie is good.

27:37 - Yeah, well, you're right.

27:39 And you can always, sorry, cookie's good.

27:42 You can always start with just write it the simple way and then add the stuff if you need it, right?

27:47 Are you really feeling the pain that these kind of patterns would solve?

27:51 Okay, bring it in, right?

27:53 You got refactoring tools, you got tests, right?

27:54 - Yeah, and the other thing with the, I mean, solid includes things like the Liskov substitutability principle.

28:01 How arrogant does that sound?

28:03 I mean, it's one of the things that I have a problem with.

28:06 It just reeks of, "I'm smarter than you because I know about this stuff." And I just don't like that.

28:13 Yeah.

28:15 It's a cool article, though.

28:17 The solid principles are good to know, even if you're not using them everywhere.

28:21 It's good to know, like, these are some design principles, and I'm choosing to use them here, - You have to use them there because, right?

28:27 - Yeah.

28:28 - Do it consciously, right?

28:29 - Definitely.

28:30 - Speaking of making choices and trade-offs, Instagram wrote a cool article recently that I thought would be fun to cover 'cause it's a look inside how they're running their Django app.

28:40 They want to basically take typed Python, like typed annotations, which they're loving, right?

28:46 They actually did a PyCon presentation or I don't know if it's officially under Instagram, But Lucas Lenga covered basically how they're using types at Instagram when he was there.

28:59 And that was really, really interesting.

29:01 But they were like, look, we have a few HTTP endpoints.

29:04 They've talked about how they're not doing microservices.

29:07 They have a single Django app, and it has a few thousand HTTP endpoints in the one app on top of other stuff.

29:15 That is a lot of API endpoints.

29:18 And they all exchange like rich types with validation.

29:23 And so they asked the question, are methods in code have type annotations?

29:30 We can check that with mypy and stuff like that, but how do we have developers know whether their APIs are still matching what they should be?

29:42 Because everything returns a JSON response, everything takes an HTTP post or a JSON object, and what are you going to do with that, right?

29:50 So they went on this mission to try to add this typing to their API.

29:55 So they came up with this decorator that they can put on a regular typed method that converts it to an HTTP endpoint in Django.

30:03 - Okay.

30:04 - Right, so I've got a regular function, it just declares its variables, it declares they're of this certain type, it returns them of another type, and you just decorate this thing, and boom, it becomes an HTTP endpoint that returns JSON based on what it exchanges JSON based on what comes in and what goes out, which is pretty cool.

30:24 So that's a start, and it says, well, you're still just returning JSON responses, so how do you get better validation than that?

30:29 So they decided to start using data classes or data exchange, because data classes have a type.

30:35 They can be immutable because you can set the frozen decorator on them.

30:37 They have type validation through things like mypy and whatnot, which is all really cool.

30:43 But remember, they have millions of lines of code and thousands of endpoints in a single Django app and they're not gonna go, well, you know what?

30:50 We're gonna upgrade every single interaction to use data classes, right?

30:53 There's a bunch of dictionaries still going around.

30:56 So have you heard about TypedDict?

30:58 - Yeah, it's neat.

30:59 - Yeah, it's really cool.

31:00 So that comes out as one of the mypy extensions and it lets you create a dictionary but then also express the types.

31:06 like this key is supposed to be an integer and this key is supposed to be a date.

31:10 And so for the older code that couldn't be written with data classes, what was just dictionaries, they added in typed dicks to help give validation to that and type explicit type definitions.

31:22 Instead of saying this thing returns a dick, it can return a type that is a type dick, but still is compatible with API.

31:27 So that's pretty cool, right?

31:28 - Yeah, this is interesting.

31:30 - Yeah, it's super interesting.

31:31 And so they also talked about how do we dot, So once we have these APIs and they have types and they have type validation, how do we communicate that back to people?

31:40 So they leverage OpenAPI to come up with very nice documentation.

31:45 If you got the article open, Brian, you could scroll down and you can see like a very beautiful API reference that was just automatically generated out of the API methods.

31:54 - Yeah, OpenAPI is really nice.

31:55 - Yeah, so that's really cool.

31:56 Now, what's also interesting is they go through this whole process of what they've done and how they've done it, and this is on Medium, implicitly, it's on their blog, but their blog's running on Medium.

32:08 So you can go and see the comments in there, and a lot of people are like, hey, this is cool, why don't you use Pydantic?

32:13 Which we've covered Pydantic before, it solves many of these problems for data exchange and validation.

32:19 Another person's like, you should use FastAPI, 'cause FastAPI has this typed API methods natively at the boundary, you don't have to have this decorator that'll transform them into Django.

32:31 - That's really cool.

32:32 But all of these are like, hey, I know you have a couple million lines of code for a huge project in production.

32:39 Why don't you rewrite that in FastAPI?

32:42 No, right?

32:43 That's just not going to happen.

32:43 - They're already in Django.

32:44 I mean, yeah, I was thinking, oh, it's kind of like FastAPI, except for they're in Django, so it's different.

32:49 - Yeah, exactly.

32:50 I mean, who wants to take on the job of rewriting the entire millions of lines of code when they've just gone through the process of going, upgrading Django, and upgrading from Python 2 to 3, and so on.

33:01 So there's a bunch of interesting comments about alternative ways to solve this problem if you were starting from scratch.

33:07 But I think it's also interesting to think about that.

33:10 Now one thing that did come out that they could use, somebody said, this is cool, and if you have typed APIs and nice documentation and you're already using OpenAPI, why don't you check out SchemaThesis?

33:23 SchemaThesis?

33:24 - SchemaThesis.

33:25 - SchemaThesis.

33:27 So it's a tool for testing your web apps based on their API definition.

33:32 So it goes in reverse.

33:34 It looks at the documentation and it says, okay, we're going to call your endpoint according to the documentation and see if it really matches that or not.

33:42 - Yeah, it's really cool, actually.

33:44 - Yeah, so I think that that's actually pretty neat.

33:46 I've never used this.

33:48 Can't necessarily recommend it, but it seems pretty interesting if you've already got the open API stuff in place.

33:52 So I like that.

33:53 - Yeah, Alexander Holtner brought it up, the Schema Thesis Project up when we, I talked to him on testing code 107, and it sounds pretty neat.

34:02 - Yeah, yeah, very cool.

34:03 All right, well, that's it for our main items.

34:05 Brian, you got anything else you wanna share with folks?

34:08 - One of the things we've done for the past couple of episodes is talk about the current COVID-19 stuff and working from home.

34:15 We didn't mention that at the beginning, but I've got, like, actually, I wanted to just take this section to bring up some things that I'm running into.

34:24 And I'm curious if any of our listeners have some comments, but I'm curious about you as well, if you have any suggestions.

34:30 So you don't normally switch between Windows and Mac, is that correct?

34:34 - No, not usually.

34:35 And if I, actually if I told you, I just got bootcamp booting into it, and it's driving me crazy because even when I was using Parallels, I remapped Control + C to be Command + C.

34:46 So even in Windows, I could do Command + C, Command + V, and in Windows, I could do Command + W to close a window, but now I gotta do Alt + F4, but oh yeah, the crazy touch bar thing doesn't have function keys, so now how to do Alt+F4 with no function key.

35:02 Like there's just a bunch of like, yeah, it's a challenge if I'm not running a VM, so yes.

35:08 - Okay, so I've got two laptops, one of them runs Windows, one of them's running Mac, it's a Mac, and so I've got my setup with my monitor and my keyboard and everything, and I can switch between them.

35:21 I would love to have just a magic switch, but apparently USB switches don't happen.

35:27 So I just plug in the USB-C from one to the other.

35:30 So if anybody's got a switch that they know about, great, but I don't want to pay like $1,000.

35:35 I was thinking like 50.

35:37 Anyway, what I'm noticing is this whole, the Control + C thing.

35:40 So on Mac, it's Command + C, Command + V, all that stuff, it's great.

35:45 And then it's Control, that's the thing I'm messing up, is the copy and paste and all that stuff is different on the two.

35:53 So any idea, is it easier to, can you remap on a Mac?

35:57 Can you make it do Control C and Control V also?

36:00 - I think so.

36:00 I'm pretty sure you can.

36:01 You can go, one thing that I do all the time on the Mac is if you go to the keyboard preferences, and then you can go in there, you can go to shortcuts.

36:08 And so I'll go to the app shortcuts.

36:12 So if you go to app shortcuts, you could add a new one.

36:15 You could pick all apps or just one.

36:17 So you could go and say edit means, paste means this, copy means that.

36:22 And it might not always work, you might have to add it for different apps 'cause it has to match the menu item exactly.

36:28 So if one is like, I don't know, copy and paste, or I don't know, like paste with a capital P or a lower P or a dot dot dot or not a dot dot dot, those would not be compatible, but you could go in there and add the shortcuts and just say control V means paste or paste dot dot or capital P paste or whatever you gotta do for a few of 'em, and then I bet you could map it over like that.

36:50 - Yeah, I'll check that.

36:51 The other thing that you could do that I used for a little while is I had a Windows machine and a Mac at the same time on two different computers, and I set up a network KVM, which is kind of what you're talking about, and it lets you actually just have two monitors on two computers side by side, and the mouse will just move straight across from one to the other computer without changing stuff.

37:13 So there's a place called sharemouse.com.

37:16 I cannot recommend it.

37:17 I've never used it.

37:18 I can't seem to find the one that I used to search for and use back like five years ago.

37:23 But like a network KVM switch is what you want, or something like that.

37:27 So check that out.

37:27 That might let you actually have both at the same time.

37:30 Maybe you can remap command to control across that as well.

37:34 - Okay.

37:35 The other thing is, so we're on episode 177, right?

37:39 We've done most of these episodes where I'm using a laptop, and now I'm using a monitor.

37:46 Is it distracting to do, and it's nicer to me, to look at you while I'm talking, but is it distracting to see somebody looking sideways while you're talking?

37:57 - Right, right, 'cause your camera's on your laptop.

37:59 But your main high-risk monitor is in front of you without it.

38:03 It's not distracting to me, 'cause I'm used to it.

38:06 There's so many video calls that I'm in these days where it's some sort of setup like that.

38:11 I think I'm just overtaking it personally.

38:13 The person never looks at me.

38:14 Or you just don't really like the way I look, and you're always like, oh, geez.

38:18 (laughing)

38:19 No, I'm just kidding.

38:20 No, I think it's okay.

38:21 I do have a Logitech.

38:23 I have my MacBook, and it would be off to the side as well where the camera is, but I got a little USB camera to go at the top.

38:29 - Okay, maybe I'll get a USB camera.

38:31 - Yeah, who knows.

38:33 - Okay, anyway, that was it.

38:34 And also, for some reason, I've got an hour and a half extra with no commute time, but I don't know where it goes.

38:40 I don't seem to have more time in the day.

38:43 I seem to have less time.

38:44 But anyway.

38:46 - Maybe you're more accessible.

38:47 I mean, you used to be like kind of accessible to the people who were near you.

38:51 Now the entire company has equal access to you and your time, right?

38:57 I booked it on your Outlook calendar.

38:59 Like, oh no, not my Outlook calendar.

39:00 Don't even look at that.

39:01 (laughing)

39:03 - Anyway, okay.

39:04 So enough about me.

39:05 - I don't know where my time goes either, but yeah, although I don't have more, I've lost getting used to that.

39:10 Although I did have to drive my daughter to school and sometimes, and that time is back.

39:15 So yeah, I guess I have some time as well.

39:17 I have a quick follow up, really, really quick.

39:19 So we talked about SuperString and their benchmarks last week.

39:22 And the benchmark showing that SuperString is much faster on Python and lower memory usage on Python for a bunch of operations and whatnot.

39:31 And I convinced Matt Harrison to cover it and whatnot.

39:36 But on Twitter, a couple of people were like, "Hey, I looked at the code and I don't really know where the memory improvements are coming from." If you look at the benchmark stuff, Honestly, I don't know how much better it is or isn't.

39:47 I haven't dug super deep into it.

39:49 But it looks like a lot of the improvements in speed are around slices and new string creation is not necessarily that much better.

39:58 Anyway, I just wanted to link to a conversation with Anthony Sottile and a few other folks who are chatting about that.

40:05 So might want to jump in if you really care about Superstring.

40:08 - Yeah, and also I'm glad you brought it up because I really love that people are calling us on stuff.

40:12 Like people pay attention and go, hey, wait a second.

40:16 You covered something, and I don't think that it's as cool as you think it is.

40:21 That's why we have awesome listeners.

40:24 Usually the feedback is, you covered this one thing.

40:26 Did you know there are seven others like it that you've never heard of?

40:29 We're like, no.

40:30 Or why did you cover this other thing you don't know about?

40:32 Well, because I didn't know about it until now.

40:34 Are you ready for a joke?

40:35 I am so ready.

40:36 This one is a little bit--

40:38 we've covered this before, but like 75 episodes ago or something like that.

40:43 So I feel like it's okay to cover it again because I've talked a lot about Windows, Windows subsystem for Linux.

40:48 You just talked about the sharing keyboard around it.

40:52 So, you know, in all good nature joking at Windows, here's a joke.

40:57 So do you know how many programmers it takes to kill a cockroach?

41:00 - No, how many?

41:00 - Two.

41:01 One holds, the other installs Windows on it.

41:03 (laughing)

41:05 - That's funny.

41:06 It takes way more than one person to install Windows.

41:08 (laughing)

41:09 - That's right.

41:10 (laughing)

41:11 Oh, fun.

41:13 All right, well.

41:14 - That's good.

41:14 - Good topics this week, Brian.

41:16 Thanks for sharing them with me and with everyone.

41:17 - Thank you.

41:18 - You bet, bye.

41:19 - Bye.

41:20 - Thank you for listening to Python Bytes.

41:21 Follow the show on Twitter via @PythonBytes.

41:23 That's Python Bytes as in B-Y-T-E-S.

41:26 And get the full show notes at pythonbytes.fm.

41:29 If you have a news item you want featured, just visit pythonbytes.fm and send it our way.

41:33 We're always on the lookout for sharing something cool.

41:36 On behalf of myself and Brian Aukin, this is Michael Kennedy.

41:40 Thank you for listening and sharing this podcast with your friends and colleagues.