Brought to you by Michael and Brian - take a Talk Python course or get Brian's pytest book


« Return to show page

Transcript for Episode #166:
Misunderstanding software clocks and time

Recorded on Wednesday, Jan 22, 2020.

00:00 OKKEN: Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is Episode 166, recorded January 22nd, 2020. I'm Brian Okken.

00:11 KENNEDY: And I'm Michael Kennedy.

00:12 OKKEN: And this episode is brought to you by Digital Ocean, we'll talk about them more later. But do you want to get into the quantum stuff? Or, what have you got for us first?

00:12 KENNEDY: Yeah, how about that? There were many crazy ideas in programming, right? Like, infrastructure as code, or infrastructure as a service, and all the cloud computing things. And, you know, there's this really cool quote from William Gibson, the science fiction writer, is that, "The future is here, it's just not evenly distributed." Which is pretty cool. And I think this thing we're about to talk about is a little bit about making that way more even. So, Amazon, AWS, the bookstore, is announcing quantum computing as a service.

00:56 OKKEN: Okay, we were expecting this to happen.

00:58 KENNEDY: Yeah we were, well, the thing is though, quantum computers are so early stage, they're so specialized, they look more like science projects than they do any sort of computer. They're not in square boxes, they're usually like dangling from the ceiling with all sorts of wires shooting out of 'em. You know, you can't go get a quantum computer. But there are quantum computers that can do limited amounts of computing. And so learning to program them is something that might be a good idea, right? Like, I have no idea what programming a quantum computer's going to feel like, 'cause it's just the conceptions, I just haven't formed it fully in my mind. Do you have a good sense of what it's going to be like?

01:39 OKKEN: No, well, I think we're at the punchcard stage still.

01:42 KENNEDY: Yeah, yeah, exactly. So this new service called Amazon Braket from AWS is a fully-managed service that allows scientists, researchers, developers, and people just interested in quantum computing to begin experimenting with computers from multiple quantum hardware providers in a single place. So there's a handful of people creating these quantum computers and they have different capabilities and whatnot, so you can actually select more than one provider for your quantum computer. So, we all know about bits, right? Bits are zero and one, on off, that sort of thing, that's the conception in my mind that it's pretty easy for things to work. But quantum computers use a more sophisticated representation known as a qubit or a quantum bit, and each qubit exists in a state of one or zero, but because of its quantum nature it also in superpositions of one or zero, which means it can simultaneously occupy both states. So it's basically a two-dimensional vector, of complex numbers of all these different states, which means it has way more data representation and computing power than just zero or one. It has near-infinite. So, this service is built to give people some basically hands-on experience programming this. So I linked to the Verge article talking about this. I also linked to the direct announcement. Now, Brian, do you see that code section down there, that little example?

03:09 OKKEN: Yes. I have no idea what it's going to print.

03:12 KENNEDY: I have no idea what it's going to print either, but if not carrying, one, the computational output is, what does that remind you of?

03:20 OKKEN: Python.

03:21 KENNEDY: It definitely looks like Python. And in the announcement you can say, "And here you can use a notebook to explore writing in this Braket, service Braket language." And yeah, so I don't know if this is literally Python or it's just very very much like Python, but, if you're a Python developer, you can get into this pretty easily I would suspect.

03:39 OKKEN: Yeah, it definitely looks like it's a notebook or something.

03:42 KENNEDY: Yeah, so, if you want to know how quantum computers work, if you want to play with programming them, check this Amazon Braket thing out. I've not checked the pricing. It seems like it might not be that cheap, but, yeah, it still looks pretty nice...

03:56 OKKEN: Well, I think they're really trying to make it available to people that, in a researcher student situation, so it's probably not terrible. But I dunno.

04:05 KENNEDY: Yeah, yeah, who knows, but it's definitely interesting, and people who are interested can now go and just fire up a quantum computer in the cloud and, with through a Jupyter notebook, play with it, which is pretty awesome.

04:15 OKKEN: Yeah! So let's go from quantum to virtual.

04:21 KENNEDY: Yes, let's do it, do it, take us away.

04:23 OKKEN: Couldn't resist, but, not really that cool. But anyway, virtual environments, right, with Python. I know that both of use virtual environments...

04:32 KENNEDY: All the time.

04:33 OKKEN: I still have coworkers that don't, and I know that some people still, I don't know, there's a lot of old guides and tutorials on how to use virtual environments, and I really didn't know I needed this, but, Brett Cannon wrote a quick and dirty guide on how to install packages for Python. And it is mostly just basically walking people on how to use virtual environments. I, of course, already know how to do that, but I think it's good to have something like this available to throw to people that aren't using 'em yet, 'cause it's pretty short and simple. One of the things I love about the article is it uses the --prompt flag for creating a virtual environment, which will make it so that your prompt variable, or the prompt isn't just venv, it's something useful for you to see it.

05:17 KENNEDY: Yeah that is super cool, I love that recommendation about the --prompt. In the article, Brett shows you how to have it take the current working directory as a default, right? So it'll automatically grab that for you, which is cool.

05:33 OKKEN: I've got a little Bash snippet that I use that essentially does that in my environment. He hints at, that in Python 3.9, there's going to be an improvement, that instead of having some code that looks up your current directory name, that you can just pass in a dot for the prompt, and it will just name it that, which, I'm looking forward to that, that's cool.

05:57 KENNEDY: Yeah, that's really cool. Maybe I just want to start running 3.9 beta, just for that.

06:02 OKKEN: Maybe. Have you started playing with 3.9 yet?

06:05 KENNEDY: No I haven't.

06:06 OKKEN: Okay.

06:07 KENNEDY: I'm still actually, I'm still trying to decide what version I want to use, because traditionally I use Homebrew, and something went wrong with Homebrew for Python 3.8, so if you try to install Python 3.7 from Homebrew, sorry Python 3 from Homebrew, you still get 3.7, which is frustrating, but I haven't decided that I'm wanting to break away from that just yet. But it's starting to get to the point where maybe I'll just go to 3.9.

06:31 OKKEN: I dunno, I just still use the installers from the python.org site, but...

06:35 KENNEDY: Yeah, I'm going to be back there too. But yeah, this is cool, and it's nice to have this, this is real clear and concise and, yeah, thanks Brett.

06:43 OKKEN: So, do you know what else is cool? Digital Ocean is pretty cool.

06:46 KENNEDY: Digital Ocean is awesome.

06:47 OKKEN: Yeah, so Digital Ocean's sponsoring this episode. They have awesome infrastructure and an awesome product, and we use them for our services. Do you have a memory-intensive workload? Something like high-performance SQL or NoSQL databases, in memory caches like Redis, or indexes? Some kind of large data analysis runtime? Well if so, you need Digital Ocean's new memory-optimized droplets, or at least you should check them out. So check them out by going to pythonbytes.fm/digitalocean, and get a $100 credit, and that's back, we used to be lower but now it's 100, yay.

07:22 KENNEDY: Yay, well done Digital Ocean, thanks for supporting the show. Sometimes, the best thing you can do Brian is just say no. Alright, it's easy to say yes to everything, but, you say yes to something you're actually saying no to something else.

07:35 OKKEN: Yeah I've heard that, that's like, kind of like the whole pointing your finger and three point back at you, and stuff like that, but.

07:41 KENNEDY: Yeah exactly, so, this next thing I want to talk about is something that made the rounds last couple of weeks, and it's pretty interesting. It's the article that sort of lays out a case against the no code movement, and it's entitled Say No to the no code movement, by Alex Hudson. It's funny, I don't know, I might be showing my age, via my gray bits in my beard or whatever, my goatee, but he starts off by talking about, 2020's going to be the year of no code, a movement where you can write business logic, even entire applications, without having to train a software developer. I feel like I've heard that before, last century even. How about you?

08:18 OKKEN: Well, yeah. Are we talking like round trip stuff like UML round trip things?

08:23 KENNEDY: Yeah I was thinking of like Visio and some of these other business intelligence, draggy droppy things, that we're going to, quickly replace us as software developers, and we're just going to be out of a job. So you probably shouldn't study that, 'cause either outsourcing or this no code stuff is going to crush our jobs. And, I dunno, I feel like software has been pretty good over the last 20 years.

08:45 OKKEN: Yeah, that's weird, so.

08:47 KENNEDY: So the reason I'm bothering to cover this though, is I do think it's interesting that, this is something of a trend, and I think that Alex does a pretty good job of laying out what some of the issues are. It's easy to get sucked into wanting this, but it's also good to maybe know where like, hey, this might make sense, to try this, this no code idea. So, examples include Salesforce. Right, with Salesforce you could sort of wire stuff together to make things happen. Other examples were Zapier, were doing things.

09:20 OKKEN: Yeah, maybe if this then that.

09:22 KENNEDY: Yeah, If This Then That. I feel like Zapier actually, Alex gave it a pretty good vote, and I agree as well, because it's not so much about trying to write software with Zapier, it's about trying to just do integration. I feel like no code integration isn't terrible if something awesome like Zapier can do it. But, basically, the idea is like look, people want to transform business processes into the software domain. And they might want to do that because change control, like how do you change your business and understand how it works is now a software problem. It's easier to innovate on what makes the business distinct 'cause now it's, like, these are the things we do, everyone does this, but this is our special sauce right here. And there's a cool quote from Satya Nadella, that says, "Every company is a software company these days." And so there's a lot of pressure to take maybe traditional companies and organizations that don't have a software team, or they have a very small software team that's too busy just keeping the lights on, to help everyone else with their little issues, there's this temptation to say, "Okay, well what is our no code story? How do we get some systems that just let people write code." Excel sort of played that role to a large degree. So the article's good for laying out some of the issues. Starts out well, the first assumption is that writing text, like writing business logic in text form, is something that everybody hates, right? Outside of the software development community, if I'm an accountant, and I want to write text logic, because, you have to be accurate in things like that, right? If you had boxes you could drag 'em together, that might be better. So, talks about how, it's a simpler abstraction, that's really easy to work with. Or it's simpler syntax, and in both of those cases, you really run into the problem of well, you can do the simple little thing first. Like think of a visual, like a flowchart, right? If you could just run a flowchart. Well for a really simple problem it's fine, but if you try to solve a real problem, you have a flowchart with a thousand boxes and lines going everywhere. That's not going to help you. Another example of the issues you run into is that, many of the no code advocates are building significant systems by pulling together off-the-shelf apps and integrating them. This is kind of like Zapier. But, Zapier I think, even while it's still good but, the problem is, all the logic becomes implemented as a configuration of all these external systems, and you're limited by what they can do and what they can accept, and so on. Yeah. He said look, if there was a better way to create software than writing text, most of us would just drop it like a hot rock, I would be like "Yeah okay, what's next, let's do that." It would be great. It's not that we love typing so much. So I guess, in conclusion, it's like where does the no code stuff fail in practice? Well you get like 80% of the way there, and then you're like "Well all these edge cases make this so complicated." Or you end up with all the little edge cases and details that is like, this little graphical whatever, is so complicated that it's worse than text. Things like that. But where it might be useful is for little proof of concept demonstrations and, things like that. Like hey, here's the happy path of the main thing we want to do, I threw this together with something like Salesforce or some other BI tool or something, and look what we got. Then you could go rewrite that with Python and matplotlib, or whatever it is you're trying to solve. So I thought this was an interesting take on the whole no code movement, and I also thought it was interesting that like, this year's going to be the year of no code, when, I remember hearing that in the 90's.

13:00 OKKEN: Yeah actually, my first job at HP was using a visual language for measuring systems, and it was, I think we should at some of the failures of the 90's, because what happened is going to happen again. Like you said, you have systems that go 80% of the way, but the corner cases make it so that you still have to be an expert at this tool to do it, so you still hire programmers, but they only are gaining experience with this one tool that they don't even really like, and they can't transfer to any other job, and that's terrible, it's not good. Plus, visual stuff is sort of really fun when you get started, but you quickly need a wrist brace. Working with a mouse all day long is really actually fatiguing to your hands.

13:47 KENNEDY: That's a good point. I hadn't even thought about that, but oh yeah, for sure.

13:51 OKKEN: There was a program called V, VE now, I don't think it's even in place anymore. It was a visual thing, and we used to joke that, if you buy the boxed set it comes with a wrist brace, so.

14:02 KENNEDY: Yeah, that's not good. You know, this next item that you got comin' up here, I checked this out, and this is some deep stuff here. Tell us about it.

14:11 OKKEN: So this isn't really a topic that we normally cover, but it's also something that I was pleased and surprised to see come up with the North Bay Python. I'm going to highlight Sha and his full name is Shadid Wallace-Stepter, I think, but he says he goes by Sha. He spoke at North Bay Python and, we're linking to an article that is his article but also includes a link to the video of the presentation at North Bay Python. And it's called What I Learned Going from Prison to Python. And, it is Python-related, but the Python take comes in the end, like the last few minutes. It is a 40 minute video but you can even just listen to it because there's no visuals. I'm not going to really summarize it too much, other than this is an amazing story, and people need to listen to it. He's talking about how he went from a generational poverty situation to crime as a teen, it's interesting that he talks about one of the reasons why he started doing some crimes. It wasn't because he needed to, it was because he had zero control over the rest of his life, and that made him, it was something he felt he had control over. And then that gets him to the point where his best friend dies on his shoulder by being shot, and then he ends up in prison, and spends 19 years there. 19 years of a 27 year sentence. But, this fight that he had to do to just, to fight against the entire system trying to keep him in poverty or keep him in prison, it is an incredible story of, for him, but I think it also talks about how, regardless of your politics, poverty and the prison system in our country is broken and we need to fix it, so, that's what I wanted to highlight.

15:58 KENNEDY: Yeah, the thing that touched me from this, was I think for the first time maybe ever, I understood why people would go down some of these paths. Because, people make some of these decisions, and they're just so clearly a bad idea, you know what I mean? Thinking of like, drug addicts for hard hard drugs like heroin or meth, or people who are burglarising houses, and armed robbery and stuff, and just think, man, there's got to be a better way. But listening to his story I really understood it, and I didn't get all the way to the end, so, it's awesome that Python, it sounds like, helped him move beyond that, but do you have the last bit of the story? Or are you going to give away too much?

16:46 OKKEN: No, I don't think it'll give it away. I think, he ends in a very positive note on talking about the open source community. He eventually gets into, he goes from studying law to studying entrepreneurship, to meeting Jessica, I'm going to get her last name wrong, Jessica McKellar.

17:01 KENNEDY: McKellar?

17:02 OKKEN: McKellar. Yeah, McKellar,

17:03 KENNEDY: That's right.

17:04 OKKEN: Although he said, he met her in a journalism setting but she was, not very good at journalism or wasn't a journalist or something like that, but anyway. She's a great person. But one of the things that people face when they come out of the prison system, especially if they came in in a poverty situation, is, they've got no skills and no job history or things like that, or they may have no skills. And even if they do have skills, who's going to hire 'em? But the open source community is just a, everybody's welcome. In coding, there's more situations in coding where, I don't, either of you can do the job, and that equality of background of just, it's just about whether you can get stuff done, it isn't just about that, we also have, you have to be able to communicate, and things like that. But we don't really care as much about your college pedigree or anything, it's either you're a great coder or you're not. And that's a cool story. And he even equates the open, he was shocked by the open source community just working on stuff and giving it away. But he apparently, there was a program at San Quentin that O'Reilly gave a bunch of laptops there so that people could watch some of the O'Reilly training videos there, and that's how he learned Python, so that's cool.

18:23 KENNEDY: Yeah, that's super cool. Yeah, I loved the story, and it was really different. So, I'm happy he shared it, and I'm happy you covered it. Speaking of covering things, have we covered the GUIs?

18:32 OKKEN: I don't think so. We should probably cover GUIs.

18:34 KENNEDY: We probably should. You know what I really like about our listeners and our audience is, they really help round us out, you know what I mean, Brian? Like I'll bring up one thing, I'm like, "Oh, I heard of this one thing, can you guys believe this is a thing?" And they're like, "Here's the seven others, and here are the trade-offs, and did you know about this?"

18:54 OKKEN: Yeah, and "I can't believe you haven't covered this already!"

18:56 KENNEDY: Yeah, exactly, so I've already got a bunch of stuff on queue that has that take to it. But here's one called, QUICK, QT5-based GUI generator for ClicK, so ClicK is an argparse-based command-line interface tool or framework I guess, where you put decorators onto functions and say these are some of the arguments, these are required, these are not required, and these are the types, and so on. And it lets you write command-line interfaces. And so QUICK will take those and naturally understand the message given to ClicK, or argparse, and then create a GUI out of it.

19:39 OKKEN: No way!

19:40 KENNEDY: Yeah, that's pretty cool, right? So you don't hardly have to do anything other than throw a quick.run and give it a function or something to that effect, and off it goes.

19:49 OKKEN: Oh that is cool. Yeah, totally going to try this out.

19:52 KENNEDY: Yeah, it's not super popular. Like, it's got 62 stars and four contributors. It was changed this month, so, that's cool, but just the example. So it's a little bit old, but I think it's an interesting take, and an interesting idea, and now, if it's going to work for people they can definitely check it out and contribute to it. So on, so, yeah, I think this is a nice one. It's based, or inspired, not based on, inspired by Gooey, G-O-O-E-Y, which is also really really nice but you have to be a little bit more explicit on how it presents the UI for Gooey. You got to say "I want a calendar widget for this thing", or whatever. But yeah anyway, it'll even let you still run your standard ClicK-based CLI app the same, but then if you throw in a --gui it'll turn it into a GUI, even if you just want to change the command-line arguments. Which is, yeah, it looks pretty nice.

20:43 OKKEN: Yeah, a GUI it, it's an interesting function call.

20:47 KENNEDY: Yeah, so thank you Ricky Teachey for sending this along, and recommending it. It's a good one.

20:54 OKKEN: Yeah, thanks. Okay, we're not to jokes yet, but I have kind of a funny one coming up. So it's interesting, so, there's a couple of articles, I think it's in a series. Falsehoods programmers believe about time.

21:08 KENNEDY: Wait, what is the title of the blog? Infinite Undo.

21:14 OKKEN: Oh really?

21:16 KENNEDY: Yeah, it's all, it all fits together, I love it. Sorry, keep going, there's a second follow-on one.

21:20 OKKEN: Must be a Vi person. More falsehoods programmers believe about time, Wisdom from the Crowd edition. So, I'm sorry I can't find your name on the blog, but, wrote this article about falsehoods. The interesting thing is very few of them have links to tell you why they're false. But, these are all assumptions that are wrong. I mean it starts with, there's always 24 hours in a day. There are things that we just sort of know are kind of wrong sometimes, like when we change the time, it's different. Months have either 30 or 31, a week begins and ends on the same month, and I think these are, he's coming from the standpoint that he's debugged and tested code that had these weird assumptions in them that broke. And then it gets into some stuff that I'm going to highlight just a handful, but there's a whole bunch. A system clock will always be set to the correct local time. And if that's not true, well it'll be set to a time that's not wildly different from the correct local time. And if that's not true, well at least it'll always have a consistent offset in the number of seconds. And yeah no, that's not true either. I've been bit by this, where we had systems under test be not even on the same day. And there's the following other one, let's see, the day before Saturday's always Friday. I had to look this one up, because I'm like, isn't it? Isn't Friday always before Saturday?

22:38 KENNEDY: Alright, what's the deal there?

22:40 OKKEN: Samoa decided to change which part of the international timezone they were on so that they were the same day as Australia.

22:49 KENNEDY: And that gap swapped it, like it swapped on Saturday but it happened in the middle of the week or something like that?

22:55 OKKEN: Yeah, it happened like Thursday night, and then the next second it was Saturday morning. So they skipped Friday once.

23:03 KENNEDY: That's some serious Daylight Savings action going on there.

23:05 OKKEN: And then the number 81, the last one on the second one is, I think it's just thrown in as a joke, I hope. Software will never run on a spaceship that is orbiting a black hole. Do we have spaceships that orbit black holes?

23:18 KENNEDY: Not yet. Not yet, but you can have legacy code, you're going to have the black hole bug that you got to go back and fix.

23:24 OKKEN: Yeah, and then what I didn't highlight was that there's not an int to time, didn't put a link in for this, but, did you know that, if you have a 32-bit time counter, it's probably going to break in 2038 or something like that?

23:37 KENNEDY: Oh wow, think of all the consulting opportunities.

23:40 OKKEN: I know, it's like Y2K all over again.

23:42 KENNEDY: Exactly. Exactly, yeah, that's interesting. Real-time obviously, you think, doesn't stop, probably won't stop for us, but computer time. Computer time is, it's a whole different deal. Yeah, this is really interesting, and like, you highlighted a few of the 81, and then that didn't even touch on the more falsehoods. Pretty cool. I get a little nervous every time I get near a timezone, so, with code.

23:42 OKKEN: Yeah, I always use a timezone package, or a time package, to deal with that for me, because I know I'm going to get it wrong.

23:42 KENNEDY: Yeah, absolutely. So, I must've forgot, because I feel like last time we, a couple of weeks ago, we did cover REMI, which is a GUI framework? Right, and so REMI, yeah I remember, you brought that up. So REMI's cool, and it lets you write Python code that then gets turned into something that has an HTML representation. But then you can hook events from HTML back into your Python code. Right, it's kind of like Electron JS, but swap out the JS for Python, right? Well, we got a message from the creator, David. And he said, "Hey, thanks so much for covering that. You threw out that like hey, it would be awesome if this was an added editor, or something like that." So, yeah, you just look, a /editor in the repo. There's a drag-and-drop WYSIWIG editor for this UI.

23:42 OKKEN: That is so cool. I haven't tried it yet, but it's neat.

23:42 KENNEDY: Yeah, it looks really cool. It's like, pretty much like what you would expect. You've got all the widgets you can drag and drop in there, and size them, and set their colors, and set all their CSS properties, and then also wire up button to existing functions, or JavaScript events to existing functions and things like that.

23:42 OKKEN: You can totally waste an entire afternoon and look like you're workin'.

23:42 KENNEDY: Yeah, exactly. Yeah, like here's some of the no code stuff that is good. So it's got a little, a little walkthrough example of creating a Hello World button clicker, type of GUI app, but yeah, it actually looks pretty killer.

23:42 OKKEN: I don't want to diss people that actually work in the world of creating really good user interfaces, and that's needed, and I applaud them. But there's a lot of us nerds that just need some kind of GUI that just sort of works, and that's good enough.

23:42 KENNEDY: Yep, alright Brian, I have queued up a joke. A visual joke that we'll have to describe through here, and because this is about testing. I'm going to let you take it, it's really simple, but it's quite funny.

23:42 OKKEN: I actually peeked at this before, we're going to link to a Twitter post that somebody did of this little video. Says two unit tests, zero integration tests. And I guess, I got to say, I'm a huge fan of these unit test pass, integration test fail things, so send them my way if you find 'em. This one's hilarious.

23:42 KENNEDY: So let me describe a little bit, I'll set the stage. There's one of these super-powerful hand dryers, and there's a trash can, and it's not like a trash bin that you move around, it's affixed to the wall, right? Okay, go ahead.

23:42 OKKEN: Alright, and then right next to it it's a place where you can grab, napkin, or your paper towels also to dry your hands, but they've put one of those, the hand dryers that blows down, and it turns on with motion, and so as soon as you throw away a paper towel, the dryer blows all the paper towels out of the garbage.

23:42 KENNEDY: It's super-strong, not just the one you tried to put in the garbage, but every paper towel that was previously in the garbage, is now blasted around. Two unit tests, zero integration tests.

23:42 OKKEN: Yeah, the creative people that got the garbage liner to stay in there in the first place, it's hilarious.

23:42 KENNEDY: It got a little or something sticky on there to keep that thing in place. That's pretty funny.

23:42 OKKEN: This reminds me of, I was at a company where we switched from actual plants around the office to plastic plants. But nobody canceled the watering service, and so the watering service just kept going around and watering all the plastic plants, once a month. Or once a week, or whenever they did that. So, anyway.

23:42 KENNEDY: Yeah, that probably didn't turn out well after they filled up. That sounds...

23:42 OKKEN: Weird. Well thanks Mike.

23:42 KENNEDY: You bet, thanks for being here, as always it's fun. Bye everyone.

23:42 OKKEN: Thank you for listening to Python Bytes. Follow the show on Twitter at pythonbytes, that's pythonbytes as in B-Y-T-E-S. And get the full show notes at pythonbytes.fm. If you have a news item you want to feature, just visit pythonbytes.fm and send it our way. We're always on the lookout for sharing something cool. This is Brian Okken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.

Back to show page