Transcript #34: The Real Threat of Artificial Intelligence

00:00 Michael KENNEDY: 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.

00:00 Brian OKKEN: And I’m Brian Okken.

00:00 KENNEDY: We’ve got some great stuff to share with you. But Brian, to let everyone know, this episode is brought to you by Rollbar. Check them out at pythonbytes.fm/rollbar for some good stuff. We’ll tell you about that later.

00:00 Right now, I want to hear about logging.

00:00 OKKEN: I’m one of those people that knows that I should use logging more, instead of just print statements. But to say it mildly, the standard library logging package is not intuitive.

00:00 KENNEDY: It’s definitely not obvious. You’re like, ‘I’ve got a logger, it doesn’t work. Why? What do I do now?’

00:00 OKKEN: Yeah, the setting up the config, I still get confused about it. I welcome new logging packages to try to clean that up. There’s an article that came out, “Easy Python Logging with Daiquiri”. Daquiri is a logger that is a little bit cleaner and works pretty good. I played around with it a little bit. It uses colors in the terminal, of course, which is nice. It supports file logging and it supports journald, 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 set-up, although you do have to call a git logger and call a setup function, but it’s not too bad.

00:00 KENNEDY: Yeah, it’s really similar to the built-in logging actually, which is super nice. The two things that I like, well three things, you just create it and it works. You don’t have to configure it a bunch. The other thing is that it prints color messages to standard out or standard error. So, if the thing is an error, it comes our red. If it’s good it comes out bluish. Warnings are yellow, things like that.

00:00 OKKEN: 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.

00:00 KENNEDY: The other things that’s sweet is that it does native logging of exceptions. So, even if you don’t catch the exception, it will print out the exception details.

00:00 OKKEN: That’s cool, I missed that.

00:00 As I was thinking about this today, I saw somebody mentioning logzero, so I went and checked that out this morning. There’s a link to it in our show notes. But it’s also pretty clean and it has no external dependencies and also does color on the output. If you are doing a quick and dirty thing, there’s no setup required at all.

00:00 KENNEDY: Yeah, that’s pretty interesting. The logo of that one is a beaver with a hardhat and some plants, which is pretty interesting.

00:00 OKKEN: Yeah. One of the things I’d like to say about daquiri 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 daquiri wrong.

00:00 KENNEDY: Yeah, I’m not sure I’d spell that correctly off the top of my head either.

00:00 OKKEN: Both are fun projects, so check them out.

00:00 KENNEDY: Yeah, if you throw in logging in there, also check out logbook. It’s by Armin Ronacher from Flask.

00:00 I have a deep article, a deep thought for us for the next one. Python is probably the biggest space where artificial intelligence (AI) is done. A lot of the AI, machine learning, algorithms come out from Python first or at least come with Python right out of the box. So, TensorFlow, Keras, a bunch of the other things that you might do, would probably be done in Python.

00:00 So, there was this interesting article that was in the New York Times of all places, called, “The Real Threat of Artificial Intelligence”. We so often hear people talk about AI, the singularity and super scary stuff. Elon Musk said last year that he’s pretty sure we live in a simulation, which I’m pretty sure is silly. What do you think about that?

00:00 OKKEN: (Laughs) That’s pretty silly.

00:00 KENNEDY: It’s a fun mind game to think, it’s like a philosophy, prove-you-exist sort of thing, but how real is it and even if it is real, what can you about it? Whatever, it doesn’t matter.

00:00 But this article says, ‘Let’s look at what the implications of AI for society are.’ So, AI is going to be reshaping work and what jobs mean. I’m not sure if it will affect programming or not, whether AI will actually replace programmers or we’ll just program AI; we just might shift around a little bit. But if you do anything with AI, I recommend that you check this out. It’s really interesting about the effect that it’s going to have on the industry, basically on all of society in general. Some of the things they said, like, there are so many jobs that are going to be dramatically affected by this. The number one job for men in the United States is driving. 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?

00:00 These kinds of things are interesting to think about. The other part was sort of geopolitical, like how do countries 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. There are other search engines but they don’t come close to Google, for example. It will probably be like that for AI. Countries that own the powerful AIs will be even more in-equal with the rest of the world. If you’re thinking about AI and you’re doing AI and machine learning stuff, this is a really interesting, philosophical read.

00:00 OKKEN: Yeah. It’s also not just the people with the AI but also the people with the datasets, that control the datasets.

00:00 KENNEDY: That’s a huge part of it, absolutely. Who’s collecting the data now that can be fed to these AIs that make them stand out?

00:00 OKKEN: One of the things that I liked about this article was AI can sometimes seem still far out when we’re trying to think about driving cars and stuff. But the model that, right now, that is used for AI is just anytime where you take a whole bunch of data to use algorithms to decide on what decisions for a particular circumstance. 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 a lot of loan representatives are replaced by AI machines.

00:00 KENNEDY: I could see that basically being 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?

00:00 OKKEN: Yeah. Also, they even talked about customer service. They’ve got voice recognition things going on that are pretty darn good, they’re not great, but they’re well enough to where your first level of contact through phone service is probably going to be a computer not too long from now.

00:00 KENNEDY: With all these ‘smart speaker’ type things, that’s going to push that technology way out.

00:00 This article does have a bit of a dark view of 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. One practical example and then we’ll move on – 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 solve police violence problems. They said if they use machine learning to figure out that is a police man goes and handles 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 are still upset from that previous thing. That was discovered through data science, things like this. There will be a bunch of good stuff coming out of it, but it’s interesting the effects on society and the jobs here.

00:00 OKKEN: It’s something to keep track of. It’s nice.

00:00 KENNEDY: Alright, so let’s move from a society philosophy to the philosophy to physics and science applied to programming.

00:00 OKKEN: There was an article called, “The Three Laws of Config Dynamics” and yes, that’s ‘config’ like configuration files. I ran into this recently myself. The article starts out talking about the birth of a configuration file for a project. 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.

00:00 KENNEDY: Right. As soon as you have a dev database and a production database.

00:00 OKKEN: Yeah. Like in the book I’m working on, I have a config file to control. It’s a little task list application. I support both MongoDB and TinyDB, so I have to tell the application which one to use and where it is. Those are things that just happen.

00:00 The article – after coming up with how they’re created in the first place – talks about these three laws. One of them was, ‘Config values can be transformed from one form to another and not be created or destroyed.’ 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.

00:00 KENNEDY: I love the parody to ‘The Three Laws of Thermodynamics’.

00:00 OKKEN: 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 and your config file see if you can condense them or combine them, or somehow limit them.

00:00 KENNEDY: Yeah, that was a really interesting one. I thought it was a good reminder that these things need maintenance and cleanup, just like the rest of your code, or it can get nasty.

00:00 OKKEN: This one surprised me when I read it. The last one is ‘Number three, the length of a perfect config file in a development environment is exactly equal to zero.’ That’s saying you should be able to run an application with no configuration file when it should be fairly valid. If it isn’t then, you’ve got to have some way for each developer to come up with what their default config file should be.

00:00 KENNEDY: For example, you could have the dev database hardcoded in, but if it’s past some other value like a production or staging database that will just use that instead. So, you don’t need to specify the dev database similarly for outbound email, just go, ‘If there’s nothing here, we just don’t send email. But if there is something we’ll send it to this SMTP server.’

00:00 OKKEN: It also talked about Docker helping it. Since I’m not a Docker user, I just kind of got lost on that section. (Laughs)

00:00 KENNEDY: Yeah. 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 Docker you can consistently name the machines the same thing in production in a development and it’s the same. So, the database server can just be called DB. The API address can just be API, or whatever. You have different containers running in production versus development.

00:00 OKKEN: Okay. That makes sense.

00:00 KENNEDY: You can hardcode the name but change the infrastructure to just match it.

00:00 So, I want to talk about Jupyter Notebooks next, but before we do let’s talk about Rollbar.

00:00 Rollbar has been a long-time sponsor of the show. I’m sure a lot of you know the job of Rollbar is you integrate it to your apps, especially web apps. If there’s any kind of error it gives you tons of information. So, I’ll touch on a few things I haven’t last time. They support Python, of course, which is great and that’s why they’re a big part of this community. They actually support 26 languages and frameworks, so Python but also Node.net, and they even support Flash. If you have an error in your Flash app, that you somehow got stuck with, plug it in.

00:00 Another thing that they have that’s pretty cool is they have what’s called people tracking. So, if you have users, anybody logged into your app, one of the problems if is somebody reports an error to you. ‘I did this thing and it didn’t work.’ I’ve 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. You can go to your dashboard and say, ‘Find that user and see all the errors and workflow to your app they ran into. Find this error.’

00:00 It’s pretty cool. Check them out at pythonbytes.fm/rollbar. It helps support the show and it’s a cool product.

00:00 OKKEN: Before we get onto Jupyter Notebooks, 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. I’m really proud that Rollbar sponsors the show.

00:00 KENNEDY: That’s awesome, very cool. My Rollbar t-shirt is quite threadbare these days.

00:00 Okay, so let’s talk about, ‘Five Tips to Get You Started with Jupyter Notebook’. How are you with Jupyter Notebooks? Do you use them often?

00:00 OKKEN: no.

00:00 KENNEDY: I don’t either. Mostly I do web stuff with tons of files and they’ve all got to fit together so the workflow is just not that way for me. Also, I often feel like I should really just get in the habit of firing up a Jupyter Notebook for certain types of work. This is a nice little article by the ActiveState folks about how to start really quickly, easily with Jupyter Notebooks.

00:00 So, the five tips are: Don’t put your entire code into a single cell. You have these little cells, you put fragments of code and the cells work together, so you get the output of each step. If you break it apart, you can execute the steps independently, you can have the data flow from one to the next. There’s different types of cells. You can put Markdown or you can put Python code or you can put a picture, all kinds of stuff.

00:00 You can build up a story with the code. You can execute shells with shift + enter. This is not the ActiveState guide, this is Esri. You can explore maps and you can integrate the ArcGIS stuff into it.

00:00 They have a really cool way to get information about modules you might know about. So, you type, ‘Import daquiri?’ and it will give you a summary of what you can do with daquiri

00:00 There’s a few simple things you can do with Jupyter. Hoperfully, this inspires you to check it out and try it for when it makes sense.

00:00 OKKEN: Awesome. What’s next? Oh, coupling.

00:00 KENNEDY: Coupling versus de-coupling. Tell me about coupling.

00:00 OKKEN: This is an article by Kent Beck. I’ve followed Kent Beck since I was reading about extreme programming and test-driven development.

00:00 KENNEDY: Yeah, he’s one of the original Agile Manifesto guys, extreme programming, all that stuff from back in the day.

00:00 OKKEN: I ran across this article and I was confused. It’s called, “Cost of Coupling Versus Cost De-Coupling”. I’m like, ‘Why is he posting this on Facebook?’ But he works at Facebook, so that makes sense.

00:00 Two elements are coupled with respect to a given change, if changing one element implies changing the other. That makes sense for coupling. When you’re writing tightly coupled code, it’s hard to change things because every time you change one thing you’ve got to change a bunch. If you do copy and paste coding all over the place and if you fix the algorithm, you’ve got to fix it everywhere.

00:00 Other places where coupling often creeps up is very tightly coupled test and implementation with mocks and whatever. If you decide to change part of the design, you have to change all the tests. Some people are okay with that, whatever. But in de-coupled code it’s the opposite of that. It follows the DRY principle and uses smaller components.

00:00 But the nice de-coupled code also takes more time to write and design initially. So, the article is just talking about thinking about the costs of both and understanding that there are places for both of them in your development.

00:00 Kent splits in into Explore and Extract; maybe those words are more meaningful to him, but that isn’t very obvious to me. The Explore phase being spike or first draft of your implementation or happy path. The point of that, your first writing through a project is 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 final draft or architected stuff. Economies of scale take over and you need to minimize the cost of changes so you do the opposite of that.

00:00 KENNEDY: I think one of the things that’s interesting about this is it’s easy to study deign patterns or these types of things and say, ‘Oh, I’m going to apply this to everything I do from now on because this is amazing.’ But if you’re building something that’s 5,000 lines and just you are going to work on it, you’re just going to be spending extra effort to apply these patterns in de-coupling and whatnot, when you could just write it and be done. Whereas, if a team of people is working on it and it’s 100,000 lines, it’s going to live a long time and be obtainable and evolve, these things make a lot more sense. So, definitely think about the trade-offs.

00:00 OKKEN: And also, as your project goes into maturity, the code base is going to get larger and it’s going to cover little corner cases that aren’t really obvious. So, your tests are going to cover those little corner cases and be more tightly coupled as well.

00:00 That was good to think about and make sure you’re okay with hacking things together at first if you’re learning stuff.

00:00 KENNEDY: Yeah, sometimes it’s worth it just to hack it together.

00:00 Alright last one for me is an inspirational little project. A lot of people out there ask me, ‘Hey, Michael. I want to get started in programming in Python. I want to build up some kind of portfolio that I could show people to get a job or to get a promotion,’ whatever. So, the guys over at PyBites – not Python Bytes, PyBites – Bob and Julien, you can see the link on the show notes. They did the 100 Days of Code Challenge. Have you heard of this, Brian?

00:00 OKKEN: I’ve been sort of following them along with this.

00:00 KENNEDY: They’re pretty good at giving information about what they’re up to because part of their challenge was that they wrote a bot that would automatically tweet the process, their process each day and there’s 100 days. They were just going after it.

00:00 OKKEN: One of the things I wasn’t clear on, did they start the 100 Days of Code?

00:00 KENNEDY: I don’t think they started it. I think they said, ‘We’re going to do it for Python.’

00:00 So, they have all sorts of stats and pictures and stuff. The article, the write-up we’re referencing, is really cool. They wrote about 5,000 lines of code split across 100 scripts per day. The number of lines was 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’ve built that they’ve showcased. Some of them are really neat. Like I said, they auto-tweeted their progress. They ran some analysis across their scripts, their 100 scripts, and figured out they used exactly 100 modules. That’s a weird coincidence, right?

00:00 OKKEN: Wow.

00:00 KENNEDY: So, 100 different modules is part of it. Their next 100-day project is going to be around Django, so if you are interested on Django follow them on Twitter or however they send out their messages about this stuff.

00:00 If you are interested in getting started, check out their article. It may help you have some small, concrete daily things you can do and 100 days later you’ll have a lot more experience.

00:00 OKKEN: Yeah. I think it was Bob that was at PyCon?

00:00 KENNEDY: Yes.

00:00 OKKEN: I ran into Bob and talked with him a little bit. Great guy. I like what they’re doing. One of them already knew Python to begin with and the other one was brand new, had never used Python before as they started the PyBites thing.

00:00 KENNEDY: Cool. That’s our news for the week. What else have you got for us? What’s up with you? A good review of your book, I just read it.

00:00 OKKEN: Yeah, I ran across the first review I’ve seen so far for the book, by Chris Shaver. We’ll have a link in the show notes. It was nice to see a book review of it. It’s fun to have more people reading it. It’s good.

00:00 KENNEDY: Yeah. It was really a good write-up and it summarized it well and gave it a good vote of confidence, so it was well-deserved.

00:00 OKKEN: How about you?

00:00 KENNEDY: Finally, after a very long time, a long journey, kind of book-like duration… “Python for Entrepreneurs” course has finally, officially been finished and it’s ready to go. It came in around 19 hours of content. You can get it at talkpython.fm/launch. I’m super excited to be done with that course – it came out great – and move on to writing new courses.

00:00 It took so long I actually wrote two other courses and finished them while that was getting finished.

00:00 OKKEN: Would it had been faster if you focused on one?

00:00 KENNEDY: 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 some bugs so I could finish another section. There was just lots of waiting. (Laughs)

00:00 But it’s all good, it’s all done.

00:00 OKKEN: Wonderful.

00:00 KENNEDY: So, it’s good to see our projects getting out to the world.

00:00 OKKEN: Well, thanks again for talking with me this week.

00:00 KENNEDY: You bet and thank you everyone for listening. Bye, Brian.

00:00 OKKEN: Bye.

00:00 KENNEDY: Thank you for listening to Python Bytes. Follow the show on Twitter via @pythonbytes and get the full show notes at pythonbytes.fm. If you have a news item you want featured, just visit pythonbyes.fm and send it our way. We’re always on the lookout for sharing something cool. On behalf of myself and Brian Okken, this is Michael Kennedy. Thank you for listening and sharing this podcast with your friends and colleagues.