Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 34, recorded July 12, 2017.
I'm Michael Kennedy.
And I'm Brian Okken.
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/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 non-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 welcome to look at, or 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 uses colors in the terminal, of course, which is nice.
It supports file logging.
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 or 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 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 also pretty clean, and it has 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 little bit, you
don't, there's no setup required at all.
Yeah, that's pretty interesting.
Anyway.
And the logo of 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, yeah.
If you're throwing logging in there, also check out Logbook, another good one.
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 on 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, you know, 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, 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.
Yeah.
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 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 and 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 a 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.
Yeah.
Here's my information.
I want a loan.
Okay, you can have it.
No, you can't have it.
Here's why.
Yeah.
You know what I mean?
And also like first level, I mean, they even talked about customer service.
And when we've got like 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, then we'll move on is shout out to the partially derivative
guys, the other podcasts 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 for like configuration files.
And I ran into this recently myself.
I've got, and they talk, the article starts out talking about how a project can 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.
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 a config values can be transformed from one form to another, but can not 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,
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 was a good reminder that these things need maintenance
and trimming and, and clean up 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, the last one is a 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
passed 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 app on email, 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.
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 like the database server could just be called DB.
The API address could just be API or whatever.
And like you have different containers running in production versus development or whatever.
Oh, okay.
That makes sense.
So you can 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, you know, 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 error 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'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.
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/Rollbar.
It helps support the show and it's a cool product.
Before we get on to Jupyter Notebooks, I have to 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 like 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 ActiveState 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.
You can execute shells with shift enter.
This is not the ActiveState guys.
This is Esri, ESRI.
Anyway, you can explore like maps because you can integrate their ArcGIS 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 import 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 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.
So 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 writing tightly coupled code, it's hard to change things because things, 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 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, and decoupled code is the opposite of that.
It follows the dry principle and uses smaller components or 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 a 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,
and learning enough about the, whatever you're working in to, 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, 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 and it's a hundred thousand 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, the code base is going to get larger and it's going to cover a little corner cases.
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 a good to think about and to make sure that you okay with hacking things together at first, if, 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 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 or whatever.
Right.
So the guy who was over at PyBytes, not Python bytes, PyBytes, P-Y-B-I-T-E-S.
That's Bob and Julian.
You can see the link in the site, the show notes.
They did a hundred 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 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 progress each day.
And there's a hundred days.
So they were just going after it.
One of the things I wasn't clear on, did they start the hundred 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 writeup 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 they're really, some of them are really neat.
Like I said, they auto tweeted their progress.
They ran some stuff, some analysis across their scripts, their 100 scripts and figured out they
used exactly 100 modules.
Wow.
So weird coincidence, right?
So a hundred different modules as part of it.
And their next a hundred 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 and about this stuff.
But anyway, if you're interested in like getting started, check out their article.
It may help you have some concrete things, small concrete daily things you can do.
And a hundred 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, as they started
the PyBytes thing.
So yeah.
Very, very cool.
All right.
What else you got for us?
That's, 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 well, the
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 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's came in around 19 hours of content and you get it at talkpython.fm/launch.
So I'm super excited to be done with that course.
It came out great and 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 second.
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 Okken, this is Michael Kennedy.
Thank you for listening and sharing this podcast with your friends and colleagues.