Python Bytes - #166 Misunderstanding software clocks and time

Episode Date: January 27, 2020

Topics covered in this episode: Amazon is now offering quantum computing as a service A quick-and-dirty guide on how to install packages for Python Say No to the no code movement What I learned going from prison to Python A real QUICK → Qt5 based gUI generator for ClicK Falsehoods programmers believe about time Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/166

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 Ocken. And I'm Michael Kennedy. And this episode is brought to you by DigitalOcean. We'll talk about them more later. But do you want to get into quantum stuff or what do you got for us first? Yeah, how about that? Like, there were many crazy ideas in programming, right? Like, infrastructure as code, or, you know, 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 I'm about to talk about is a little bit about

making that way more even. So Amazon, AWS, the bookstore is announcing a quantum computing as a service. Okay. We were expecting this to happen. Yeah, we were. Well, the thing is the 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 like all sorts of wires shooting out of it. And like, 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 is going to feel like because it's just the conceptions. I just haven't formed it fully in my mind. Do you have a good sense of what this is going to be like? No. Well, I think we're at the punch card stage still.

Yeah, yeah, exactly. So this new service called Amazon Bracket from AWS is a fully managed service that allows scientists, researchers, and 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 the 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 uh section down there that'll example yes i have no idea what it's going to print i have no idea what's going to print either but if not caring what the computational output is what does that remind you of uh python it definitely looks like python

and in the announcement you can say and here you can use a notebook to explore writing in this bracket service bracket language and yeah so i don't know if this is literally python or is just very very much like python but if you're a python developer you know you can get into this pretty easy i easily i would suspect yeah it definitely looks like it's a like a notebook or something yeah so if you want to know how quantum computers work if you want to play with programming them you know check this amazon bracket thing out i've not checked the pricing it seems like it might not be that cheap but uh yeah it still looks pretty 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 don't know yeah yeah who knows

but it's definitely interesting and uh people who are interested can now go and just fire up quantum computer in the cloud and with through a jupiter notebook play with it which is pretty awesome yeah so let's go from quantum to virtual yes let's do it do it okay i couldn't resist but you know not really that cool but anyway virtual environments right with python i know that both of us use virtual environments all the time i still have co-workers 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 they i really what didn't know i needed this but uh brett cannon wrote a quick and dirty guide 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 them yet because it's pretty short and simple. One of the things I love about the article is it uses the dash dash prompt flag

for creating a virtual environment, which will make it so that your prompt variable or the prompt isn't just V and V. It's something useful for you to see it. Yeah, that is super cool. I love that recommendation about the dash dash prompt. And 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. 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 yeah that's really cool maybe i just want to start running 3.9 beta just for that um Maybe. Have you started playing with 3.9 yet? No, I haven't. I'm still actually 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 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 i don't know i just still use the installers from the python.org site but yeah i'm gonna be back there too but yeah this is cool and it's it's nice to have this this is real clear and concise and yeah thanks brett so, do you know what else is cool?

DigitalOcean is pretty cool. DigitalOcean is awesome. Yeah. So, DigitalOcean is 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 DigitalOcean's new memory optimized droplets or at least you should check them out. So check them out by going to pythonbytes.fm slash DigitalOcean

and get a $100 credit and that's back. It used to be lower, but now it's $100. Yay! Yay! Well done, DigitalOcean. Thanks for supporting the show. Sometimes the best thing you can do, Brian, is just say no. All right. It's easy to say yes to everything, but when you say yes to something, you're actually saying no to something else.

Yeah, I've heard that. That's kind of like the whole pointing finger and you three point back at you and stuff like that. Yeah, exactly. So this next thing I want to talk about is something that made the rounds the last couple weeks since it's pretty interesting it's an 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 and it's funny i don't know i might be showing my age my my gray bits in my beard or whatever my goatee but he starts off by talking about 2020 is going to be the year of no code,

the movement where you can write business logic, entire applications without having to train a software developer. I feel like I've heard that before, last century even. How about you? Well, yeah. Are we talking like round-trip stuff, like UML round-trip things? Yeah, I was thinking of like Visio and some of these other sort of business intelligence, draggy-droppy things that were going to, you know, quickly replace us as software developers. And we're just going to be out of a job.

So you probably shouldn't study that because either outsourcing or this no-code stuff is going to like crush our jobs. And I feel like software has been pretty good over the last 20 years. Yeah, that's weird. 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. So 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 uh this no code idea so examples include like salesforce all right with salesforce you can sort of wire stuff together to make things happen other examples

were zapier for doing things yeah maybe if this than that yeah if this than that i feel like zapier actually you know 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, there's 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 because now it's clear.

You're like, these are the things we do. Everyone does this. But this 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. And 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. It starts out, well, the first assumption is that writing text, like writing business logic in text forms is something that everybody hates right outside of the software development community right like if i'm an accountant i don't want to write text logic because well you have to be accurate and things like that right and if you had boxes you could drag them together that might be better so talks about how you know there's 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 flow chart right like if you could just run a flow chart well for a really simple problem that's fine but if you try to solve a real problem you have a flowchart with like a thousand boxes and lines going everywhere yeah that's not going to help you another one 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 you know zapier i think user is 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 so 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 right we'd We'd be like, yeah, okay, what's next? Let's do that. All right. It would be great. It's not that we love typing so much. Yeah. 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 you know things like that but where it might be useful is for a little proof of concept demonstrations and things like that like hey i'm here's the 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, right? Then you could go rewrite that with Python and Matplotlib or, you know, 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 is a year is going to be the year of no code when I, you know, I remember hearing that in the nineties. Yeah, actually my first job at HP was using a visual language for measuring systems. And I think we should look at some of the failures of the 90s, because what happened is what's 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 on the mouse all day long is really actually fatiguing to your hands. That's a good point. I hadn't even thought about that. But oh, yeah, for sure. It was a program called VEE. And 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 box set, it comes with a wrist brace. Yeah, that's not good. You know, this next item that you got coming up here, I checked this out and this is some deep stuff here. Tell us about it. So this isn't really a topic that we normally kind of 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 Shaw and his full name is Shadeed Wallace-St wallace stepter i think but he says he goes by

shah he spoke at north bay python and uh the 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 um 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 um need to listen to it he's talking about how he went from a generational poverty situation to a 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 it made him, it was something that he felt had control over. And then that gets him to the point where his best friend like 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 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 why I wanted to highlight it. 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? I'm thinking of like drug addicts for hard, hard drugs like heroin or meth or people who are burglarizing houses and robbing, 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? No, I don't think he'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. I forgot it. Jessica McKellar? Yeah, McKellar. Sounds right. 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 a 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 them? But the open source community is just a, everybody's welcome. And coding, there's more situations in coding where I don't care either, you can do the job. that equality of uh of background of just it's just about whether you can get stuff done it isn't just about that we also you have to be able to communicate and all things like that but we don't really care as much about your uh college pedigree or anything it's

either you're a great coder or you're not and that's a cool story um and his even equates the open he was shocked by the open source community of just working on stuff and giving it away yeah but he apparently there was a program at san quentin that o'reilly gave a bunch of laptops there so that people could watch uh some of the o'reilly training videos there and that's how we learned python so that's cool man super cool yeah i loved his story and it was really different. So I'm happy he shared it and happy you covered it. Yeah.

Speaking of covering things, have we covered GUIs? I don't think so. We should probably cover GUIs. 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? Yeah. Man, 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, and here, you know, here's the seven others and here are the trade-offs. Did you know about this? Yeah, and I can't believe you haven't covered this already. Yeah, exactly. So I've already got a bunch of stuff on Q

that has that sort of take to it. But here's one called Quick, a Qt5 based GUI generator for Click. So Click is an argpars based command line interface tool or framework, I guess,

where you can put decorators onto different functions and say these are some of the arguments, these are required, these are not required, 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 argpars and then create a GUI out of it.

No way! Yeah, that's pretty cool, right? So you don't hardly have to do anything other than throw like a quick. run and give it a function or something to that effect and off it goes. Oh, that is cool. Yeah, I example so it's a little bit old but i think it's an interesting take an interesting idea and 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 GUI. You've 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 dash-dash 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.

Yeah, a GUI, It's an interesting function call. Yeah, exactly. Yeah, so thank you, Ricky Tichy, for sending this along and recommending it. It's a good one. 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 articles. I think it's in a series falsehoods programmers believe about time and wait what is the title of the blog infinite undo oh really yeah it's all like it all fits together i love it sorry keep going then there's a second follow-on one must be a vi person more falsehood programmers believe about time. Wisdom from the crowd edition. So I'm sorry, I can't find your name on the blog, but I 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. And it starts with there's always 24 hours in a day. And 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... I'm going to highlight just a handful, but there's a whole 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 will be always have a consistent offset in the number of seconds and you know 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 it has the following other one. Let's see. The day before Saturday is

always Friday. I had to look this one up because I'm like, isn't it? Isn't Friday always before Saturday? All right. What's the deal there? Nope. Samoa decided to change which part of their, the international time zone they were on so that they were the same day as Australia. And that gap swapped it like it swapped on Saturday, but it happened in the middle of the week or something like that? Yeah, it happened like Thursday night, and then the next second it was Saturday morning.

So they skipped Friday once. That's some serious daylight savings action going on there. Okay. And then number 81, the last one on the second one is, I think it's just thrown in as a joke. I hope the software will never run on a spaceship that is orbiting a black hole. Do we have spaceships that orbit black holes? Not yet. Yeah.

Not yet. But you're going to have legacy code. You're going to have the black hole bug that you got to go back and fix. Yeah. And then one I didn't highlight was that there's not an end 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? Oh, wow.

Think of all the consulting opportunities. I know. It's like Y2K all over again. Exactly. Exactly. Yeah, that's like Y2K all over again. Exactly. Exactly. Yeah, that's interesting. I mean, real time, obviously, we think doesn't stop and probably won't stop for us. But yeah, computer time, computer time is a whole different deal.

Yeah, this is really interesting. And yeah, like you highlighted a few of the 81 and then that doesn't even touch on the more falsehoods. Pretty cool. Yeah. Yeah. I get a little nervous every time i get anywhere near a time zone so with code yeah i always use a time zone package or a time package to deal with that for me because i know i'm gonna get it wrong yeah absolutely so i must have forgotten because i feel

like last time we a couple weeks ago we did cover remy which is a gui framework yeah right and so really yeah i remember that you brought that up remy'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? Yeah. 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 had an editor or something like that. So yeah, if you just look at slash editor in the repo. Yeah, there's a drag and drop WYSIWYG editor for this UI.

That's so cool. I haven't tried it yet, but it's neat. 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 clicks to existing functions

or JavaScript events to existing functions, things like that. You can totally waste an entire afternoon and look like you're working. Yeah, exactly. Yeah, here's some of the no-code stuff

that is good. So it's got a little walkthrough example of creating like a Hello World button clicker type of GUI app. But yeah,

it actually looks pretty killer. I don't want to diss people that actually work in the world of creating really good user interfaces that, you know, and that's needed. And I applaud them. killer. I don't want to diss people that like actually work in the world of creating really good user interfaces that, you know, and that's needed and I applaud them, but there's a lot of

us nerds that just need some kind of GUI that's just sort of works and that's good enough. Yep. All right, Brian, I've 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. I actually peeked at this before. We're going to link to a Twitter post that somebody did of this little video.

It says two unit tests, zero integration tests. And I guess I got to say, I'm a huge fan of these like unit test pass, integration test fail things. So send them my way if you find them. This one's hilarious. Yeah. So let me describe a little bit. I'll set the stage. There's a, one of these like super powerful hand dryers and there's a trash can and it's not like a trash bin that you move around. It's like a fix to the wall, right? Yeah. Okay. Go ahead. And then right next to it's a place where you can grab you know napkin or your paper towels also to dry your hands but they put like a one of those uh

the hand dryers that blows down and it turns on with motion and as so as soon as you throw away a paper towel the dryer blows all the paper towels out of the garbage 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 yeah yeah two unit tests yeah the creative people that like got the garbage liner to stay in there in the first place so anyway yeah hilarious yeah the rub a little syrup or something sticky on there to keep that thing in place yeah that's pretty funny this reminds me of a i was, a little syrup or something sticky on there to keep that thing in place. Yeah. That's pretty funny. 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. Yeah, that probably didn't turn out well after they filled up. I don't know. That's just weird. All right. Well, thanks. Thanks, Michael. You bet.

Thanks for being here as always. It was fun. Bye, everyone. Bye. Thank you for listening to Python Bytes. Follow the show on Twitter at Python Bytes. That's Python Bytes as in B-Y-T-E-S. And get the full show notes at PythonBytes.fm.

If you have a news item you want featured, just visit PythonBytes.fm and send it our way. We're always on the lookout for sharing something cool. This is Brian Ocken, and on behalf of myself and Michael Kennedy, thank you for listening and sharing this podcast with your friends and colleagues.