Python Bytes - #34 The Real Threat of Artificial Intelligence

Episode Date: July 13, 2017

Topics covered in this episode: Easy Python logging with daiquiri The Real Threat of Artificial Intelligence The three laws of config dynamics Five Tips To Get You Started With Jupyter Notebook Cost of Coupling Versus Cost of De-coupling 100 Days of Code at PyBites Extras Joke See the full show notes for this episode on the website at pythonbytes.fm/34

Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds. This is episode 34, recorded July 12th, 2017. I'm Michael Kennedy. And I'm Brian Ocken. And we've got some great stuff to share with you, but Brian, just let everyone know, this episode is brought to you by Rollbar. So check them out at pythonbytes.fm slash rollbar for some good stuff. We'll tell you about that later. Right now, I want to hear about logging.

Yeah, I'm one of those people that know that I should use logging more instead of just print statements. But to say it like mildly, the standard library logging package is not intuitive. It's definitely not obvious. Yeah, you're like, I got a logger. It doesn't work. Why? What do I do now? Yeah, the setting up the config and stuff.

And I get, anyway, I still get confused about it so i am uh welcome to look at all right i i welcome new logging packages to try to clean that up and there's an article that came out easy python logging with daiquiri and daiquiri is a logger that works a little bit it's a little bit cleaner and works pretty good i played around with it a little bit but it um it uses colors in the terminal of course um which is nice it supports file logging and and it's supposedly journal d which i have no idea what that is i like some of the features of it and what i really like about it is that it just sort of works right away you don't have to do much setup although you do have to call like a get logger

and call a setup function, but it's not too bad. Yeah, it's really similar to the built-in logging actually, which is super nice. And the two things that I like, one is the, well, three things. It works just like you create it and it works. You don't have to go and configure it a bunch. The other thing is that it prints color messages to standard out or standard error.

So if a thing is an error, it comes out red. If it's good, it comes out like bluish or, you know, warnings are yellow, things like that. Yeah. It does have some, I can't remember what the dependencies are, but it does have some dependencies that tripped me up at first when I was installing it. Don't know why. But then it was easy to install. Not too bad. Yeah. The other thing that's was installing it. Don't know why. But then it was easy to install. Not too bad.

Yeah. The other thing that's sweet is it does native logging of exceptions. So even if you don't catch the exception, it'll like print out the exception details, right? Oh, yeah, that's cool. I missed that. Yeah, yeah, that's slick.

And then as I was thinking about this today, I just saw somebody mentioning log zero. So I went and checked that out this morning. And there's a link to it in our show notes, but it's, um, it's also pretty clean and it has also, it has no, no external dependencies and also does color on the output and a little bit. I mean, if you're doing a quick and dirty thing, it's a, it's a little bit, you don't, there's no setup required at all. So yeah, it's pretty interesting. And the logo, that one is like a beaver

with a hard hat and like some plans, which is pretty interesting. Yeah. One of the things I'd like to say about Daiquiri is I really had to check my spelling on it. The first time I downloaded it, pip installed it, no problem. And then I went to import it and I spelled Daiquiri wrong. So it's a D-A-I-Q-U-I-R-I. Yeah, I'm not sure I would spell that correctly off the, you know, just off the top of my head either. But both are fun projects, so check them out. Yeah, if you're throwing logging in there, also check out Logbook. Logbook, okay.

It's by Armin Roedeker from Flask. I'll check that out. All right, so I have kind of a deep article, a deep thought for us in the next one. Python is probably the biggest space where artificial intelligence is done, right? Like a lot of the AI machine learning algorithms come out for Python first, or at least come with Python right out of the box, right? So TensorFlow, Keras, and a bunch of the other things that you might do would probably be done in Python. So there's this interesting article

that was in the New York Times of all places that I'm picking it from called The Real Threat of Artificial Intelligence. And we so often hear people talk about AI and the singularity and super scary stuff. Like Elon Musk last year said that he's pretty sure that we live in a simulation, which I'm pretty sure is silly.

What do you think about that? That's pretty silly. Yeah. I mean, it's a fun mind game to think. It's like a philosophy, you know, prove you exist sort of thing. But how real is it? And even if it is real, what can you do about it? Whatever.

It doesn't matter. But this article kind of says, all right, let's look at really what the implications of AI for society are. All right. So AI is going to be reshaping work and what jobs mean. And I'm not sure if it'll affect programming or not, whether AI will actually replace programmers or we'll just program AI. You know what I mean? Like we just might shift around a little bit. But if you do

anything with AI, I recommend you check this out. It's really interesting on the effect that it's going to have on the industry, basically on society in general. And some of the things they said, well, like, you know, there's so many jobs that are going to be dramatically affected by this. Like I was just telling you before we started, like the number one job for men in the United States is driving. And the combination between self-driving cars and self-driving trucks and the various other ways that automation is going to happen could easily take that down to a very small percentage of what it is today. What's that going to mean for society? So these kinds of things are interesting to think about. The other part was sort of geopolitical, like how do countries sort of evolve with AI? So once there's

an AI that can solve a problem, there's probably one that is way better than all the other attempts because they have more data. Think of Google, right? There are other search engines, but they don't come close to Google, right? For example. And it would probably be like that for AI. And so the countries that own the powerful AIs will be even more sort of unequal with the rest of the world. So if you're thinking about AI, you're doing AI machine learning stuff, this is a really interesting philosophical read. Yeah. It's also not just the people with the AI, but also the people with the data sets that control the data sets. That's a huge part of it, right? Absolutely. Who's collecting the data now that can be fed to these AIs that make them stand out?

Yeah. One of the things that I liked about this article was this kind of AI sometimes can seem still far out, even when we're trying to think about like driving cars and stuff. But the model that right now I use for AI is just any time where you take a whole bunch of data to use algorithms to decide on what decision for a particular circumstance. And like, for instance, all of the information about somebody that they turn in with their loan application, whether or not you should give them a loan. Well, I think it's going to be pretty fast if Like a lot of loan representatives are replaced by AI machines. I can see that basically be instantaneous. Here's my information. I want a loan. Okay. You can have it. No, you can't have it. Here's why. You know what I mean? And also like first level, I mean, they even talked about customer service and when we've got

like a voice recognition things going on that are pretty darn good, I mean, they're not great, but they're well enough to where your first level of contact through a phone service is probably going to be a computer not too long from now. Yeah, certainly with all these like smart speaker type things, it's going to push that technology way out. And this article does have a bit of a dark view on the world. But just think of the stuff that AI can do. There's going to be a bunch of really amazing and positive stuff. Like one practical example, and then we'll move on, is shout out to the Partially Derivative Guys, the other podcast that I heard this on. They interviewed some people who are using data science and AI type stuff to make basically to solve police violence problems. And they said, if they use machine learning to figure out that if a policeman goes and handles like something terrible, like a suicide case, and then is immediately sent back out and pulls over somebody

who talks back to them, there's a much higher chance of police violence against that driver because they're still upset from that previous thing. And so, you know, that was discovered through like data science and things like this. So there'll be a bunch of good stuff coming out of it, but some interesting effects on society and the jobs here. Anyway, it's something to keep track of. Yeah, it's nice. Yep. All right. So let's move from sort of society philosophy to the philosophy of physics and science applied to programming. There was an article called the three laws of config dynamics. And yes, that's config dynamics, like the inception of the birth of a configuration file for a project. And it often centers around something like what you're connected to, what database or what service you're connected to, and being able to control that. Right.

As soon as you have like a dev database and a production database. Yeah. Then. Yeah. Like in the book I'm working on, I had a config file to control. It's a little task list application and I support both Mongo and tiny DB. And so I have to tell the application which one to use and where it is. And those are things that just happen. But the, the article after come up with like how they're created in the first place talks about these three laws. And one of them was config values can be transformed

from one form to another, but cannot be created or destroyed. And one of the examples of that is some people recommend putting the config values in environmental variables instead, but it just doesn't really solve the problem because people just create little scripts to write their environmental variables.

And then now you've got a config file again. I love the parody to the three laws of thermodynamics. So the total length of config file can only increase over time. And I think that's just if left unchecked, one of the recommendations there is to regularly evaluate your values in your config file and see if you can condense them or combine them or somehow limit them. Yeah, that's a really, that was a really interesting one. And I thought actually, you know, it's a good reminder that these things need maintenance and trimming and cleanup, just like the rest of your code or it can get nasty. And this one surprised me when I read it at first is the last one is number three, the length of a perfect config file in a development environment is exactly equal to zero. And that's saying you should be able to run an application with no configuration file,

and it should be like fairly valid. Because otherwise, if it isn't, then you've got to have some way to have each developer come up with what their default config file should be. Right, and so, you know, for example, you could have the dev database hard-coded in, but if it's past some other value, like a production or staging database, it'll just use that instead.

So you don't need to specify the dev database. Similarly, for like outbound email, I'll just go like, if there's nothing here, we just don't send email. But if there's something, we'll send it to this, you know, SMTP server and so on. Yeah. Yeah. And then it said, it also talked about Docker helping it.

And since I'm not a Docker user, I just kind of got lost on that section. But yeah, I feel like, like we said before, Docker shifts programming experience to ops experience in a lot of ways. The way they said that Docker can help is with a Docker, you can consistently name the machines the same thing in production and in development, and it's the same. So the database server could just be called DB. The API address could just be API or whatever. And you have different containers running in production versus development or whatever. Oh, okay. That makes it hard code the name, but change the infrastructure to just match it. So I want to talk about Jupyter notebooks next.

But before we do, let's talk about rollbar. So rollbar has been a longtime sponsor of the show. And I'm sure a lot of you know, right, the job of Rollbar is you integrate it into your app, especially web apps. If there's any kind of error, it gives you tons of information. So I'll touch on a few things that I haven't last time. So they support Python, of course, which is great, and that's why they're a big part of this community. But they actually support 26 languages and frameworks, so Python, but also node.net, and they even support flash. So if you want to get air handling your flash apps that you somehow got stuck with, plug it in. And another thing that they have that's pretty cool is they have what's called

people tracking. So if you have users like anybody logged into your app, one of the problems is if somebody reports an error to you, they say I did this thing and it didn't work. You're like, oh, gosh, I got to go troll through the log files and find it, speaking of logging. But here with Rollbar, you can actually associate that error with a logged in user. And then you can go to your dashboard and say, find that user and see all the errors and workflow or flow through your app they ran into to find this error. So pretty cool. Check them out at pythonbytes.fm slash Rollbar. It helps support the show and it's a cool product. Before we get on to Jupyter Notebooks, I gotta say, I just recently cleaned out my office and found my goodie bag from PyCon

and found a rollbar sticker and slapped it on my laptop because I'm really proud that rollbar sponsors the show. That's awesome. Very, very cool. Yeah, my Rollbar t-shirt is quite threadbare these days. Okay, so let's talk about five tips for getting started with Jupyter Notebooks. How are you with Jupyter Notebooks? Do you use them often? No. Yeah, I don't either. I mean, mostly I do web stuff with tons of files, and they all got to fit together.

So the workflow is just not that way for me. I also often feel like, you know, I should really just get in the habit of firing up a Jupyter notebook for certain types of work. And so this is a nice little article, I think is by the active state folks about a couple of things you can do to just like start really quickly and easily with Jupyter notebooks. So the five tips are don't put your entire code into a single cell, right? You have these little cells, you put little fragments of code and the cells like work together. So you get the output of each step. So if you break it apart, right, you get kind of, you can execute the steps independently.

You can have the data flow from one to the next. That's cool. There's different types of cells. Like you can put Markdown or you can put Python code or you can put a picture, all kinds of stuff. So you can kind of build up a story with a code uh you can execute shells with shift enter this is not the active state guys this is esri esri anyway you can explore like maps because you could integrate their arc gis stuff into it and they have a really cool way to get information about modules you might not know about so you could type say like Daiquiri, and then Daiquiri question mark, and hit tab, and it'll, like, give you a big

summary of what you can do with Daiquiri. Oh, wow. Cool. Anyway, there's a few simple things you do with Jupyter. Hopefully, this inspires you to check it out and try it for when it makes sense. All right. What's next? Oh, coupling. Coupling versus decoupling. Tell me about it. Coupling. Coupling versus decoupling. So this is an article by Kent Beck and I've followed Kent Beck since I was reading about extreme programming and test-driven development. Yeah. He's one of the original Agile Manifesto guys, the extreme programming, pair programming, all that stuff from back in the day, right? Yeah. And I ran across this article and I was confused. At first I was confused. It's called cost of coupling versus cost of decoupling.

And I'm like, why is he writing on, like, posting this on Facebook? But he works at Facebook, so that makes sense. Anyway, two elements are coupled with respect to a given change if the change changing one element implies changing the other so that makes sense for coupling so when you're when you're writing tightly coupled code it's hard to change things because things uh every time you change one thing you got to change a bunch like if you've got if you do copy and paste coding all over the place then if you fix the algorithm you got to fix it everywhere the other thing, other places where coupling often creeps up is very tightly coupled, uh, test and implementation. So if you, with mocks and whatever, and if you, if you decide

to change, change part of the design, you got to change all the tests. So some people are okay with that, whatever, but, uh, and decoupled code of the opposite of that, it follows the dry principle and uses smaller components, whatever. But the nice decoupled code also takes more time to write and design initially. So the article is just talking about thinking about the costs of both and making sure and understanding that there are places for both of them in your development. And Kent splits it into explore and extract. And that's, maybe those words are more meaningful to him, but that isn't very obvious to me. So the explore phase being like spike projects or your first draft of your implementation or happy path, the point of that, your first writing through a project is just learning about it, answering questions

quickly and learning enough about whatever you're working in to ask better questions as you go along. And then the extract phase is more like a final draft or architected stuff. Economies of scale take over and you need to minimize the cost of changes so that you can, you know, the opposite of that. Yeah. Well, I think one of the things that's interesting about this is, you know, it's, it's easy to like study design patterns or these types of things and say, Oh, I'm going to apply this to like everything I do from now, cause this is amazing. But if you're building something

that's 5,000 lines and is like, just, you are going to work on it, you're just going to be spending extra effort to make these, to apply these patterns and this decoupling and whatnot, when you could just write it and be done. Whereas if a team of 10 people is working on it, it's 100,000 lines and it's got to live a long time and be maintainable and evolve. Well, then, you know, these things make a lot more sense, right? So definitely think about the trade-offs. Yeah. And also as you're like a more, as your project goes into maturity, the code base is going to get larger and it's going to cover a little corner cases that aren't really obvious. So it is necessarily going to be your tests are going to cover those little corner cases, and they're going to be more tightly coupled as well. So it was good to think about and to make sure that you're okay with hacking things together at first if you're learning stuff.

Yeah, sometimes it's worth it just to hack it together. All right, last one for me is just an inspirational little project, something a lot of people out there ask me like, Hey, Michael, I want to get started in programming Python. I want to build up some kind of portfolio that I can show people to get a job or to get a promotion or whatever, right? So the guy who was over at PyBytes, not Python Bytes, PyBytes, P-Y-B-I-T-E-Ss that's bob and julian you can see the link in the site the show notes they did the 100 days of code challenge have you heard of this brian well i've been sort of following them along with this they're pretty good at uh giving information about

what they're up to because they had part of their challenge was they wrote a bot that would automatically tweet the process their their progress each day. And there's 100 days. So they were just going after it. One of the things I wasn't clear on, did they start the 100 days of code or did they? I don't think they started it. I think they said, we're going to do it for Python. Okay.

Yeah. And so they wrote, they found out they have all sorts of stats and pictures and stuff. So the article, the write-up that we're referencing is really cool. They wrote about 5,000 lines of code, split across obviously 100 scripts per day. And the number of lines was like between 50 and 200 per day, which is kind of an interesting thing. They've got a whole bunch of projects.

They've got 10 projects that they built that they showcased. And some of them are really neat. Like I said, they auto said they auto tweeted their progress they ran some stuff uh some analysis across their scripts their 100 scripts and figured out they used exactly 100 modules wow it's a weird coincidence right so 100 different modules as part of it and their next 100 day project is going to be around django so if you're interested in django you know follow them on twitter or however they send out their messages about this stuff. But anyway, if you're interested in getting started, check out their article.

It may help you have some concrete things, small concrete daily things you can do. And 100 days later, you'll have a lot more experience. Yeah, I think it was Bob that was at PyCon? Yes. Yeah, I ran into Bob and talked with him a little bit and great guy. And I just, I like what they're doing. They have like one person, I can't remember who, which is which, but one of them already knew Python to begin with. And the other one was like brand new, had never used Python before as they started the PyBytes thing. So yeah. Very, very cool. All right. What else you got for us?

That's our news for the week. What's up with you? Good review of your book, right? I just read it. Yeah. I ran across the first review I've seen so far for the book by Chris Shaver. And we'll have a link in the show notes. But it was nice to see a book review of it.

And it's fun to have more and more people reading it. So, it's good. Yeah. It was really a good write-up and summarized it well and gave it a good vote of it. And it's fun to have more and more people reading it. So it's good. Yeah, it was really a good write up and summarized it well and gave it a good vote of confidence. So I think it's well deserved. Nice. How about you? Finally, after a very long time, long journey, kind of book like duration, the Python for Entrepreneurs course has finally officially been finished and is ready to go. So it came in around 19 hours of content,

and you get it at talkpython.fm slash launch. So I'm super excited to be done with that course. It came out great. I move on to writing new courses. Awesome. Yeah, it took so long, I actually wrote two other courses and finished them while that was getting finished. Well, would that have been faster?

Had you focused on one? No, because I was waiting on other people. I was waiting on editors. I was waiting on Matt to do his sections. I was waiting on PyCharm to fix a bug so I could finish another section. There's just like lots of waiting. So many things. Okay.

But it's all good. It's all done. Wonderful. All right. Yeah. So good to see our projects getting out to the world. Well, thanks again for talking with me this week. You bet.

And thank you everyone for listening. See you next time. Bye, Brian. Bye. Thank you for listening to Python Bytes. Follow the show on Twitter via 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. On behalf of myself and Brian Auchin, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.