Hello and welcome to Python Bytes, where we deliver Python news and headlines directly to your earbuds.
This is episode 76, recorded May 3rd, 2018. I'm Michael Kennedy.
And I'm Brian Okken.
And this episode is brought to you by Datadog. Check them out at pythonbytes.fm/Datadog.
They're doing awesome stuff. Tell you more about that later.
Brian, I think, you know, we're on the eve of PyCon.
We're literally, in terms of podcast releasing, podcast episodes, this is PyCon Eve.
And PyCon is a place where people seem to really care more than most developer communities about sort of welcoming newcomers.
And you've got something that kind of ties into that angle as well, right?
I ran across this article, and it looks like it's called Unlearning Toxic Behaviors in a Code Review Culture.
And this is, apparently this came from a talk at AlterConf and then turned into this.
So there's the slides are available, but there's an article with all of the information.
And this is something that trying to have good manners and be a good human while also helping each other out in code reviews is sort of an interesting balancing act.
Because you've got to actually teach people and if you need to teach and everything.
So anyway, I'm going to jump into some of the ideas around this.
And it's an interesting idea to go off.
It's a discussion of some of the unhelpful behaviors that people have seen and then some of the helpful things that you can do.
So I'm not going to list all of them, but there's a few of them that jumped out at me.
Like, passing off opinion is fact was the first one.
And, you know, it's people saying, oh, this should be implemented this way.
But there isn't really a should often with software.
Those are opinions.
And so just make sure you state it like that.
One of these things, next up is overwhelming with an avalanche of comments.
So, like, for example, if somebody made the same mistake a whole bunch of times, like, I don't know, there's spaces in the wrong place or some formatting issue or, you know, not using underscores and doing camel case instead, commenting every place.
I mean, one comment is sufficient to don't put like, yeah, you did it here too.
Yeah, you did it here too.
All over the code review.
And there's actually just reading through all of these.
They're good just reminders of how to be helpful instead of being hurtful during a code review.
And then popped out some of the helpful things that one of the things that popped out at me is collaborate and don't backseat drive.
And this is one actually that I need to work on because it's hard when I see some code that I think should be another way.
I don't really want to just tell everybody, tell somebody what's all wrong with it.
My instinct is to just do it the right way and show them, say, it should have been done like this.
But that's, you know, that's not the right way to go.
But anyway, do you have any comments on some of this?
So one of the things I think that people need to be really careful about is when in some of these code reviews, especially for junior developers, this can be like a really sort of sensitive time emotionally, right?
You put together some work and like it's one thing to criticize the code.
But at the same time, it can come across as feeling like criticizing that person or their skill set.
And, you know, when you're a junior developer, your feeling is like you maybe don't feel like you can keep up with your team because they've been doing it for 10 years and you've been doing it for two.
And you just feel a little bit like you're always trying to catch up.
Right.
And so if somebody comes in just matter of factly says, we're going to throw a bunch of comments on this stuff.
You should do it the way I've been doing it for 10 years, et cetera, et cetera.
Like it can I think it can be perceived as a personal attack or attack on your credibility in your newfound career.
So I just think, you know, being real, real sensitive to that, especially for junior developers.
Right.
I mean, I'm sure people who've been doing it for a long time feel that way as well.
But the longer you do it, the thicker your skin gets.
And you're just like, you know, the more you're kind of used to having these sort of debates and differences of opinion.
But, yeah, I would sort of second this and say, you know, be cautious of the junior developers and make it more about learning and bringing them along instead of like, hey, I'm going to show you how to do this because you did it wrong.
Also depends a lot on personality because I'm when I was a junior developer, I actually was more open for people saying, wow, this sucks.
You should do it this way.
And now that I'm I think of myself as an experienced developer, there's still a lot of stuff that I'm learning in new parts.
And I sometimes will take a comment of like, oh, you should do it this way as like we're talking about.
I'm a senior developer, you know, but I got to check the ego a little bit.
And one of the things that helped my team a lot, it shows up on this list, too, is to automate what you can.
Like, for instance, we use I mean, whatever your standard is, just define that and codify it with PyCode style or FlakeAid or something.
Our team uses FlakeAid, the FlakeAid defaults.
We at work, it was helpful for us to increase the line length and a couple other things that we turned off.
But agree on that and just automate that.
And just so sometimes something will come through a code review.
And just a simple comment of, hey, can you run this through FlakeAid first before we start the review is easier.
I totally agree with that because people you don't feel personally criticized by a computer.
Yeah.
Right.
It's just like the algorithm, it formats it this way and it checks that the line length is this and the format is that.
And if it's wrong, then you fix it.
But it's not like it's, you know, it has an opinion about that.
Not really.
Right.
Maybe someday computers will have opinions like that, but they don't right now.
Yeah.
And another thing, sort of adding on what you're saying is with black, I believe, remember black, the formatter that comes in any color you want, long as it's black?
Yeah.
That one, I believe, will modify the code, not just suggest fixes.
So you can say black, reformat this the way we like it and just do that.
I still haven't tried to hook that up as a commit hook or something like that.
Exactly.
That'd be nice.
I think it's pretty cool.
Definitely worth thinking about these issues.
So, Brian, do you remember a few episodes ago that project, that new versioning project that Mahmoud and Mahmoud Hashemi and a few of his friends put together about zero version?
Was it zero for?
What was it called?
I think it was zero for.
Yeah, I think it was zero for.
So it was like sort of celebrating in a sarcastic poking fun that maybe you should not be zero version.
The zero dot whatever version of things like Flask, Pandas, et cetera.
Right.
Things that have been around for eight years and are super stable and are still like zero dot one for their version.
Well, either that article or this episode or that episode covering it somehow may have had some kind of effect because Flask had been on like zero dot something small for eight years.
And now Flask 1.0 is released.
How about that?
I think it's a great thing.
It was interesting that there were some people that like actually commented of like, why bother if it's already stable?
I think it's a good.
I think it absolutely makes sense.
I mean, I know that there are people out there in the world who see it's been around for a long time.
It's had many releases.
Does that mean stable?
If it's not stable, you put the little beta, the little B on the end of the version or something like that.
But there's a large portion of the development world that comes to Python from outside of the core ecosystem of Python and sees zero dot one and goes, can't use it.
Not ready.
What is this?
Right.
And so I think it I think it really makes a lot of sense just changing the version because they got some pressure.
There's actually a lot of stuff here.
I'm going to try to go through this quickly because there's actually a lot of stuff here.
So the CLI is more flexible for creating a flask app.
And actually, you can do things like, say, it's in development mode or production mode, and that can replace like flask debug settings and environment, stuff like that.
That's great.
You can get the environment variables from a dot flask env file.
So instead of having to export them in your shell when you like launch the shell, like ZSHRC or bash RC, things like that, you can have it just in these files and it'll actually load them as if they're from the environment.
That's cool.
Development server is multi-threaded.
So now you can more properly test concurrent requests during development, which is what you would experience if you were released it to a proper threaded server like micro whiskey.
Flask EXT, which was deprecated, has been removed.
Some stuff around forms is pretty nice.
Better error handling, more finer grained stuff there, more logging.
For you, the test client gained a JSON argument for posting JSON and a response test object, a get JSON for decoding JSON so you can have like test your JSON methods better, a test CLI runner for testing your app's command line options.
Pretty cool, right?
Yeah, very cool.
So all of this stuff is in Flask 1.0.
Nice.
Actually, that very much deserves a bump in the version.
Right.
And it's time.
It's definitely time.
So well done, Flask team.
Yeah.
I'm just getting into some more Flask stuff, too.
So that's good.
Yeah, it's pretty fun.
So have we gotten used to pip?
Like, I'm not used to it.
I literally yesterday typed pip install-r requirements.txt a lot because I was rebuilding some servers.
How about you?
I understood it.
I think it's really cool.
But I had trouble really grokking what problem it was solving that I didn't have yet.
So I ran across an article that's called Pipenv, a guide to the new Python packaging tool.
And so since everybody's like, actually, not everybody, but it is being more recommended now to use pipenv where appropriate.
And so this article actually presented it in a way that I think it made me understand it a lot more.
For instance, using pipenv, it's like using pipenv virtual environments, but it does a lot of the stuff for you.
There is some workflow differences that I'm not going to cover here.
But there's a video up on the site that I think the pipenv readme or the, I don't know, the documents have.
Like the GitHub page.
Yeah.
It has this little video.
This is great.
It shows you the workflow.
But what problems does it solve?
So the requirements.txt has an issue.
And this article talks about the current, without pipenv, what the problems are.
So requirements.txt is, you can set it up as just, these are the required packages that my application uses.
But it doesn't really have versions.
You can put versions in there, but your mileage may vary.
Now, if your dependencies have dependencies themselves, then those versions, you know, how do you keep track of those?
So that one of the ways people have done that is use pip freeze, which does both your dependencies and all of the sub dependencies and freezes all of those.
And you can use that as your requirements file.
But then you've got to keep track of it.
So every time one of the sub dependencies updates, you've got to make sure it works.
And that's just sort of a pain.
Yeah, I mean, the requirements is supposed to show you what you depend upon, not the transitive closure of what you depend upon, really.
Right?
Oh, math words.
Not all, not your dependencies, dependencies, not the dependencies of your dependencies of your dependencies.
How's that?
Okay.
The gist of it is, in file-wise, there's two files that get generated, pip file and pip file.lock.
Pip file is the, these are my requirements, kind of, but it also does more than that.
And then pip file lock is, like, all of the pinned requirements with all the versions.
And it also includes hashes of the downloads so that you don't have to worry about corrupted installs or anything like that.
And then it does so much more than that.
But this discussion really helped me understand why this is useful, especially the subdependency thing is something, yeah, nobody wants to deal with that themselves.
So let Pip-Enf deal with it for you.
Man, pretty cool.
I got to study, I got to get my workflow zen around this new way.
One of the catches, which is that it's recommended for use for applications and not for packages because your package is used by something else.
You don't want to pin anything.
It's the application that should pin things, not packages themselves.
But you can use it while you're developing packages.
And if you're really confused on how to set all this up, there's a new cookie cutter for it.
So we're also going to include a link.
There's a package somebody did for a generic Python project that uses pipenv.
There's a cookie cutter for it.
Nice.
So basically, if you're going to start a new project, you can run that cookie cutter to generate it with the proper structure using pipfile and pipfile.lock.
And it's kind of a fun way to just get your hand like, okay, how is this all supposed to work?
Even if you don't use this for a project to pull down pipenv in a project and play with it and say, oh, yeah, this makes sense.
I think that's a really cool way.
It kind of gives you the essence of what you need for the structure, which is always something that's fun to debate.
And we have a few times.
So before we get to our next item, which is probably going to surprise people a little bit if they haven't heard of it, I want to tell you about Datadog.
So Datadog is a monitoring solution that provides deep visibility and tracks issues that you might be running into with distributed applications.
So if I have an app that has maybe some services like microservices and it calls into the database and other things and it's slow, that can be really hard to figure out where.
But with Datadog, you can just investigate the bottlenecks in your code, explore graphs and dashboards and really figure out where your app is spending its time across processes.
Right.
So not just profiling one thing.
So visualize your Python performance today.
Get started with a free trial at Datadog.
And you'll get a cool shirt, a little T-shirt with a Datadog mascot is the right word I'm looking for.
A Datadog mascot on there.
So check it out for yourself at pythonbytes.fm/Datadog.
So if you're going to think of a company, Brian, that was going to create like one virtual machine, one runtime in Python speak, the equivalent of interpreter to rule them all.
How about Oracle?
No, I wouldn't have thought Oracle.
No, I probably wouldn't either.
So there's this thing called GraalVM, G-R-A-A-L-VM.
And it says this is built to run Python code and other code that depends on virtual machines and run it faster.
So they said, look, we see this problem.
Like current production virtual machines and, you know, throw the CPython in there with that.
Provide high performance of only execution of only certain languages or a small set of languages.
They all repeat a bunch of stuff.
They all do compilation, memory management, tooling, et cetera.
So it kind of violates the don't repeat yourself, the dry principle.
They're heavyweight things usually that take a lot of memory.
So they're often difficult to embed, especially like JVM, stuff like that.
So over at Oracle Labs, they started a new project a while ago to create a single VM that would provide high performance execution for all of the languages.
Benefit being if I have, say, some sort of multilingual environment, like maybe we do Java and Python or something like that.
If you could put that within the same process and have them directly communicate, they would go dramatically faster than, say, over JSON-based microservice.
Like if it was literally in memory.
Yeah.
That's kind of the idea, right?
So the goals are basically to create this high performance single VM that can interoperate with zero overhead across these different languages and platforms.
So you can run all the JVM-based languages, Java, Catlin, and so on.
JavaScript, including Node.js.
Anything that you can do LLVM against, so C++ or Rust.
And Python.
So imagine you're doing some sort of interop type of thing, and you want to write some of your code in Rust and some of it in Python, and you want to try to get the best performance out of it.
Maybe putting it together in this thing would be pretty cool.
So it does, I don't know how much it'll help for Python in its current form, but maybe they'll get something really special.
But for some of the JIT compiled languages, it will ahead of time compile them to machine instructions and then run them.
So things like startup time and initial execution is super fast and unpredictable.
So it would be cool if they could do like PyPy pre-compiled or something like that.
Just to make sure I get my terminology straight.
The Grail VM, the VM is a virtual machine.
I'm used to virtual machines being like an entire desktop on a server or something.
Is that what this is?
No, often VMs are like the Java VM or the .NET CLR or things that are sort of managed memory process.
Okay, it's the thing between my code and my computer.
Yeah, and it is most commonly used around things that JIT compile.
Java, JavaScript, .NET, things like that.
Okay, so two completely different things.
Two different VMs.
Both called virtual machines.
Okay, got it.
Right now the Python support is experimental, but they're working on one of their main next steps is to make the support for Python better.
So if this sounds interesting to people, I think, you know, it's early days.
It's pretty interesting and check it out.
Actually, I'm like super excited about it because the combination of Python with C++ and Rust and R and other things and Kotlin, it's going to be, I think this is an exciting thing.
I think it is too.
And if you can do that with no interop within the same process that, you know, without translating between the layers and some kind of like CFFI layer type of thing, I think that would be really cool.
Yeah.
Okay.
We'll see.
It's early days, but it could be a pretty neat step in adding one more way to execute Python code.
Yeah.
All right.
What's your next one for us?
I am like totally in getting ready for PyCon mode and didn't have time to do a testing code episode last week or this week.
So this is a shameless time.
I'm going to take my last slot to do some testing related topics.
But one of them is Flask.
So we covered Flask already.
There's a brand new version.
You can test it.
Yeah.
There's an article that came out this week called Testing a Flask Application Using pytest.
And those are two of my favorite things, Flask and pytest.
And one of the third favorite thing is my own book.
And the book that I wrote was part of the inspiration for this article.
So shameless plug.
But it's a really nicely written article.
It's basically if you're writing, if you're working with Flask and you want to try to work with pytest also.
I mean, I've had questions about this, but I didn't feel qualified to answer yet.
Now I am because of this article.
But there's talks about both unit testing and functional testing through the test client that Flask provides.
But the unit tests don't have to be.
You can access things directly.
But the article goes through both a couple examples, a unit test and then a functional test.
Like, for instance, checking the making sure that a new user works at a unit test level and how to hook that up with pytest and Flask and everything.
And it's actually really nicely done.
After you read the article, I don't stop there.
I go out and look at the project that he's got on.
I can't remember if it's on GitHub or GitLab, but it's an open source project that you can take a look.
And it's got other more testing examples.
And it's really well done.
So good job.
I like it.
Yeah, it looks really, really cool.
And I see the project structure there again.
Like, here's how you set it up to do testing.
So that's very nice.
And it's cool that your book was an inspiration for it as well.
Another thing while we're on the testing topic, I wanted to bring up a new pytest plugin that just actually kind of blew me away.
This is a brilliant idea.
And I also learned the word stochastic.
I think I knew it at one point, but stochastic kind of means random and stuff.
But it comes up because it's in the readme for this project called pytest-CAPRNG.
So here's the idea is if you've used random, the random module or the numpy random is being used in your code or in your test.
Running a test, if you run a test and it fails and you try to rerun it and it passes, it might pass because the data is different.
This new plugin, what it does is before you run each test, it captures the state of the random modules so that the seeds are the same.
Next time you run it, if you rerun the failure, you'll get the same data again.
So you'll see the failure again.
And it's just kind of a small little plugin that is an awesome idea.
So I wanted to highlight it.
It's cool.
Yeah, it's cool.
I mean, coverage might change based on that value.
Success or failure might change based on that value.
So being able to lock it down, make it predictable.
Yeah.
But still have it start from something random.
That's pretty cool.
I like it.
All right.
I did say we were on PyCon Eve, right?
So the next time we release an episode is going to be at, well, at least it will have been recorded at PyCon.
We'll see if it happens there.
Anyway, there's a really nice article by Trey Hunter.
He was a guest co-host a while ago on how to have a great first PyCon.
So PyCon is maybe the big, I think it's the US one is the biggest Python conference there is.
It's certainly quite large.
And there's a lot of options.
It's a little bit of a paradox of choice there, right?
I mean, did you have that experience when you were there, Brian?
Yeah, definitely.
And I'm really having that time, that experience again, looking at the schedule.
I don't know what to go to.
I know.
I'm going to solve that by not going to anything.
Which is part of this conversation.
So he has a really nice, long, thoughtful write-up about sort of getting the most out of PyCon the first time.
You know, maybe if you've gone a few times, you can still read this and get something out of it.
So first of all, he mentions that the talks are typically recorded, available on YouTube within, I don't know, 24 hours?
Something like that.
Really surprisingly quickly.
So you don't feel like you have to attend every talk, right?
If there's something more interesting going on, don't feel like you're missing out.
You just watch it later.
I think one of my number one recommendations, which he touches on, is open spaces.
Yeah, that's actually something I didn't know about last year that I missed out on.
So that's a good thing to – what are open spaces?
There's a big board and there's a bunch of rooms.
And the rooms will hold like 20 to 50 people.
And there's probably five to ten of them.
I'm not sure exactly how many are available.
And there's parts of the conference where you can just – anybody who wants to have a group conversation about something, they fill out a little three-by-five-inch note, little card, and stick it up on the board and claim an hour in a room.
And then people just go and attend it like they would any other talk.
But it's much more high participation because there's not a proper speaker.
You just have to basically kick off the conversation.
And then it's just like a group conversation.
I think that's awesome because that's kind of what you go to PyCon for anyway is to meet with people that have similar interests.
Not just Python as a whole but specifically.
What specific parts of Python that you're interested in?
Right.
You might have like an IoT open space for people working with MicroPython or something.
Who knows, right?
That would be easily something you could put together.
The other thing is all the talks are recorded.
Almost none of the open spaces are recorded.
Yeah.
So you can't make those up.
So that's one thing I really like to do.
And Trey goes into that a little bit.
He says they're often more niche and maybe something really you want to focus – like you're really focused on.
It's all about interaction and discussion.
And they're not recorded.
So he pretty much has the same thoughts I do.
He has some tips for like conversation around breakfast, lunch, dinner.
Talks about the hallway track.
I'm a big fan of the hallway track partly because the sessions are recorded.
And partly the reason I go there is to meet people and to make connections and to have these interactions that I don't have outside of that space.
Right.
So I find almost always I'm having a great conversation with somebody and they're like, oh, the session is starting.
They're like, you know what?
Forget the session.
I'll watch it on YouTube.
Let's keep going on whatever it is we're doing because this is awesome, right?
And I find like I spend the whole conference that way.
Yeah.
It would be lame if nobody went to the talks though.
No, I know.
I'm going to go to your talk, by the way.
Okay.
I guess I think I guess more I'm saying you're right.
People, not everybody should just skip them all the time because then what would it be?
It wouldn't really be the same.
But don't feel bad about it.
Yeah.
Don't every one of them.
Right.
People find yourself in a really interesting situation that you're enjoying.
Just because it's time to go to the talks doesn't mean you have to go to the talks.
Right.
Yeah.
The other thing that I thought was interesting about this was this conversation, this concept
of a Pac-Man opening in a group.
Yeah.
I love that.
Yeah.
So the idea is like, you know, think of Pac-Man.
It's got the little open spot.
If you're in a group standing around, don't just like create a closed circle because nobody
can join or anything.
So always leave a little gap that says, you know, look for people or look for groups that have
Pac-Man openings and make sure that your group always has a Pac-Man opening.
So that's pretty cool.
Some advice for interacting online during PyCon, how to make the most out of networking and it's
not really a bad thing.
Things like that.
And also volunteering.
There's lightning talks.
Have you given a lightning talk, Brian?
Not at PyCon.
Yeah.
Neither have I.
Yeah.
It's just some general nice things.
And then finally, one I thought was interesting.
There was a person who commented on the post saying, if you're on Windows, it's helpful
to install a virtual machine image of Linux like the current Ubuntu on your laptop because
you might run into a situation, a talk or a training where something they're talking about
doesn't work on Windows and you might miss out.
That's both an opportunity for us to make the Windows experience better, but also maybe
good advice for the first person, you know, coming with your Surface tablet.
You might want to come prepared, I guess.
Or install Anaconda, something like that.
Yeah.
So one of the things I wanted to bring up that I didn't know about ahead of time is
there's certain sections of the day that is recommended that there isn't, there aren't
any talks scheduled, but what is the other floor called?
The place where we're at?
The conference hall or the?
The expo hall.
But the expo hall is pretty much open all the time.
So during a talk, if there's somebody that you wanted to meet up, meet or a company you
wanted to talk to or something that you can't get to them because there's so many people
during the normal expo times, skipping one of the talks and going during a talk time, there's
way less people in the expo hall and you might be able to catch up with somebody a lot easier.
That's great advice.
Yeah, definitely.
So I think that leads us really well into our own news.
What do you think, Brian?
Yeah.
So you brought up my talk.
I do have a talk Friday and I actually forgot the time.
It's at five something.
It's to do with testing and you're giving that a co-presenting with Paul Everett, right?
Yeah.
Paul Everett and I are going to, so I love pytest, of course, but I also have in this last year
fallen in love with PyCharm.
So we're going to do them together.
We're going to show you how to make, be efficient and effective and speed up your test and development
time with PyCharm and pytest.
It'll be fun.
Your chocolates and my peanut butter.
Yeah.
That's awesome.
And we have a booth.
You and I and a few others have a booth.
I forgot the number, but you'll find us.
It's pretty easy.
All right?
Yeah.
And we have stickers.
Yeah.
I just got my stickers this morning.
So yeah, I'll be ready.
Yeah.
It's going to be a lot of fun.
I'm really looking forward to meeting people.
So I hope everyone comes to say hello.
Yeah.
That should be awesome.
And then another thing.
We talked about the open session.
Are we planning on doing a live Python Bytes recording?
Why not try?
Let's do it.
Yeah.
Let's give it a try.
So I think we're going to do an open session live.
The next Python Bytes is coming to you live from PyCon.
It probably won't be streamed live.
Maybe we'll stream it live.
I don't know if we can get the audio to work for that.
But we'll do what we can to do a live Python Bytes and then make that the show for next week.
So if people want to get notified, they want to make sure they don't miss the time.
Because it's an open session, we can't pre-schedule it.
Right?
We have to go find a slot on that wall there.
So if people just go to pythonbytes.fm at the top menu bar, clip friends of the show and sign up there,
then I'll send out an email once we have that time figured out that day.
I'm thinking Saturday would probably be best.
Yeah, I think so.
Yeah.
Okay.
So sometime on Saturday if we can pull that off.
So that would be awesome.
Hopefully as many people can come to that.
That'd be fun.
See how the sausage is made.
Also, I'm just in a couple days leaving for Seattle.
I'm going to be at Microsoft Build.
So neat.
Yeah, that'll be really interesting.
Hang out with some of the Python folks there.
If you're at Microsoft Build and you want to come say hi, just shoot me a message on Twitter or something.
And if we're there together, that'd be great.
PyGotham, the New York City PyCon, effectively.
has just opened their call for proposals.
And PyCon DE, which is held in Karlsruhe, Germany, which is a wonderful part of Germany, very beautiful,
is also just opening their call for proposals as well.
And that's running 24th to 26th in October in Germany.
So a lot of conference stuff.
It's like conference time.
Yeah.
We have Google I.O.
We have Microsoft Build and we have PyCon all next week.
It's like they're fighting for attention.
Yeah.
Awesome.
All right.
Well, anything else, Brian?
Have we covered it all?
Yeah, I think we did.
All right.
Well, wonderful.
Well, I'm looking forward to seeing you at PyCon.
That'll be fun.
Yeah, it'll definitely be fun.
Thanks.
Yeah.
All the listeners.
Yep.
Talk to you later.
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.