Voice assistants and voice interfaces are quickly becoming the new hot way to interact with computers.
Two of the more notable ones are Amazon Echo devices and Google Home devices.
Wouldn't it be great if we could program these with Python?
And even better if we could use well-known APIs such as Flask?
This week you'll meet Eric Cho, Dave Botella, and Cam Sweeney,
who discuss their frameworks and apps they built around Amazon and Google devices.
This is Talk Python to Me, episode 146, recorded December 20th, 2017.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm.
And follow the show on Twitter via at Talk Python.
This episode is brought to you by Datadog and us here at Talk Python Training.
Be sure to check out what we're offering during the segments.
It really helps support the show.
Hey, everyone.
Quick bit of news before we get started on the episode.
First, it's 2018, and we have announced some of our 2018 courses over at training.talkpython.fm.
So there's a bunch of cool ones that are listed, and we've already shipped our first course, Mastering PyCharm.
If you're trying to get better with PyCharm, if you've tried this application that can do so much for your Python code and kind of got overwhelmed,
well, here's an eight-hour course with hands-on exercises that can really help you get better and more productive with PyCharm.
So be sure to check that out.
And if you are interested in the course or any of the other courses, we announced a new way to buy them, the Everything Bundle.
So now you can pay just one price and own every course at Talk Python Training forever.
It's way better than a subscription and about the same price.
Be sure to check both of these out over at training.talkpython.fm.
Thanks for checking out the courses.
Now let's get to the interview.
Eric Dave Kam, welcome to Talk Python.
Hey, good to be here.
Thanks.
Yeah, thanks for having me.
Yeah, I'm really looking forward to talking about talking to computers.
It's going to be a good time.
For sure.
Yeah.
So we're going to talk about Alexa.
And just a warning to everyone out there listening, if you have some kind of Echo device, some kind of Alexa-enabled device,
it's a really good time to mute it because while sometimes on podcasts we can avoid saying things like Alexa or Siri or those types of activation words,
that's not going to work for this one.
It's just not.
So put yourself on mute.
Just fair warning there.
So let's start at the beginning.
I guess we'll start with you, Eric.
How did you get into programming in Python?
Thanks for having me.
And how did I get into programming?
So you know how there are people who knew they wanted to be a programmer since they were age seven?
I'm definitely not one of those.
I'm a super late bloomer.
I think I remember not long ago I was on your show talking about getting your first gig as a software developer.
So that's kind of the timeline.
Yeah, that was episode 39.
That's like almost two years ago.
But yeah, that's awesome.
Yeah, almost two years ago.
And so I used to use...
So I've been a network engineer for most of my adult working life.
And I used Python to solve network engineering problems.
And I just kind of never looked back.
Okay, awesome.
Yeah.
And networking is increasingly becoming a programming job itself, isn't it?
Absolutely.
So, you know, software-defined networking, although the original idea of OpenFlow never took off, but it actually puts, you know, software to front and center of network engineering.
So without going too much deep into it, you know, I think it's just this fundamental shift that's going to be around for a long time.
Yeah, absolutely.
Dave, how about you?
Oh, I've always been really a hobbyist, mostly starting with my parents' TRS-80 color computer back in the day when I was a kid, working with BASIC and fiddling around with that.
Coming to Python, I honestly can't quite remember when I got started.
I think it might have been towards the end of high school, maybe sometime early in college.
I do vividly remember I kind of made a personal choice not to learn Perl and instead picked up Python.
So sometime around then.
If I look at the popularity of those two languages, I would say that was probably a good fortuitous choice there.
Yeah, most likely.
Yeah.
And Cam, how about yourself?
I'm kind of like Eric.
I didn't really get into programming until later in life.
I went to school to become a biologist and probably like the last few months of college, I just started picking up Python with automate the born stuff and just decided that's what I wanted to do.
So yeah, it's only been a few years.
I remember listening to that show with Eric on about getting your first job and that's actually really helpful.
No, that's really awesome.
Yeah.
What a crazy way to circle back, right?
Yeah, seriously.
Small world.
And now you're on this podcast with Eric.
Yeah.
Yay!
It's nuts.
Yeah, it totally is.
And so do you still do any biology or are you just doing programming these days?
Yeah, I'm just doing biology or programming.
Never even stepped foot into a lab after school.
You know what?
There's a place better for creating stuff out of bits.
Let's do that.
Yeah, definitely.
All right.
So maybe let's go with you, Kim, since we're just talking about it.
What do you do day to day these days?
Yeah.
So currently I'm freelancing and doing contract work for this company called Produvia.
It's basically using AI and chat services for just different industries.
Currently we're working on something for the hotel industry and things.
That's cool.
Is it voice assistant stuff or is it more like chatbots, like a Facebook messenger type thing?
Yeah.
So it's just been more messenger, like Slack based and like web app based.
But we're planning on moving into the voice space pretty soon.
So that's pretty exciting.
It's definitely an exciting time for that.
Dave, how about you?
I'm an independent software consultant, mostly in the enterprise space and the kind of the sexy realm of knowledge management and enterprise search.
So definitely not.
Search all the things inside of your company.
Yeah.
Not as marketable as like AI and actual chat stuff.
Yeah, but that's an important thing.
Like these companies are huge and stuff gets crammed into SharePoints that people don't know about and Excel and access.
And it's insane, right?
The back end, like real world, as I kind of call it, it's predominantly Excel.
I mean, that's the reality.
So that's where I spend most of my time, mostly in the realm of Java.
But when I get a chance to choose, I usually choose Python for some projects.
So I've got most of my experience is sort of Java and Python.
How do I get them to talk to each other, especially when dealing with interacting with any of these legacy enterprise systems?
Okay.
And you said you contribute to this thing called JPY.
What's the story of that?
JPY, yeah.
Yeah, I had a particular request from a client to deal with an old kind of proprietary binary format from a, I'm not going to say the vendor's name, but a statistical software package.
And this format had been around for a long time.
Needless to say, somebody had reverse engineered it already, which was great.
And published their findings.
And it was really wrangling bits and bytes, dealing with pages of data inside this file format.
And since this had to all be plugged into a Java program, long story short, I found it easier to solve the problem in Python.
And then I just needed to find a way to stick that inside this Java app.
Luckily, JPY, I came across as written by a consultancy in, I think, Germany, contracted to like the European Space Agency.
And they wrote it originally to deal with this kind of data interchange between some other application that the ESA uses for the scientists and everything to get data in and out.
And they wanted to use Python, like a lot of folks in the scientific community.
Right.
So I was able to take that and figure out a way to plug it in and solve some problems along the way.
That's pretty cool.
The only way that I knew about, I was aware of to do that before was with Jython.
And so is it kind of like Jython?
So it doesn't run on the JVM.
It's nice and simple in that it's basically automation and kind of data passing between the JVM and a Python interpreter.
And you can do it bidirectionally.
So from Java, you can spin up a Python interpreter and run Python code, get data back in Java using the Java native interface.
And the really cool thing is since I can't remember the person's name, but somebody did a fantastic job in the last year or so with the Windows distribution of Python.
Right.
That would be Steve Dower.
Thank you, Steve.
Yes.
Yeah.
And it's great because you can easily bundle it with something like this and pretty much ship it with your product and have an embedded Python instance.
And it's funny that it works great on Windows, yet most of the time it's a headache on Linux.
I just don't get it.
Yeah.
How funny.
That's kind of the opposite.
All right, Eric.
You're doing network stuff, right?
Like you said, just a little bit ago.
Yeah.
So mostly networking stuff.
But lately, I think for the past two years ago, it's been very focused on network security kind of accidentally.
And so within network security, very focused on distributed denial of service and use quite a bit of Python, but also other tools, whatever works for us to glean a little bit for that threat intel piece for DDoS.
Oh, that's really cool.
Yeah.
The whole computer security stuff around just both sides.
The white hat, black hat, whole thing is really Python heavy.
So that's pretty cool.
Yeah, absolutely.
And I think for us, since we're sort of a startup-ish company and certainly a small operation.
So we choose to be very focused on solving this DDoS space well.
And, you know, people talk about 10x better, and that's why we shoot for it, right?
Like if we could do 10x better than our competitor, then we're able to, people, our customers, potential customers will be able to grasp the benefits of our stuff rather than our competitors.
So that's why we shoot for it.
Yeah.
Sounds like a fun project.
All right.
So let's start out by talking about these voice assistants in general.
We're going to focus on Alexa.
They've got a really good developer story.
They've got a really good Python developer story.
And you guys have all either created some skills or worked on frameworks for creating skills.
But let's say maybe, Dave, can you give us kind of a survey of the various options we have?
We've got Alexa.
We've got Google Voice and so on.
There's Alexa Google Assistant.
Can't remember exactly what they're calling it.
Anyone can jog my memory here.
I'm more well-versed in the Amazon ecosystem or ecosystem, if you will.
Would you guys count Apple's Siri or Microsoft's Cortana in this space?
Have they opened those up with APIs and SDKs?
I actually don't know.
You know, they have so many.
Apple's so weird.
They have like NDAs for developers and stuff, right?
I haven't been paying attention for Apple.
And I also haven't been paying attention to Cortana.
Yeah.
So I don't know.
Yeah.
I would say that's probably a no last time I checked, but it was a few months ago.
For Siri and Cortana, definitely not.
But for Google, yes.
But they don't really promote it.
So it wasn't until I actually got a physical Google, I guess, mini, then I started looking at it.
And they do have a developer platform that opened up with third parties, whatever they call it, skills equivalent of Google.
So, but that's, you know, Amazon's been really at the front and center for catering to our third-party developers, I would say.
Yeah, that's interesting.
I mean, on one level or another, all of those companies have been pretty good towards developers.
But yeah, Amazon with AWS and all the stuff going on there, they're really kind of built for that, right?
You can, you know, leverage their Lambda computing to implement your Alexa skill, for example, and things like that.
Yeah, so pretty interesting.
Yeah, totally.
And also, I think they're actively going out.
So you don't see as much, say, meetup groups or trainings.
And I know they actually contracted Bignor Ranch to do Alexa trainings to bring people up to speed.
And you see, you know, a lot of Twitter feeds from their evangelists.
So I think all those feeds into the funnel of people, you know, maybe you could reach a thousand developers and, you know, maybe 10% to 1% of them actually take up.
And then you funnel it down to the people who actually were public skills.
So I think Amazon is the biggest, I guess, spread out the biggest net for these developers and then trying to catch those who are interested in the space.
Yeah.
Kim, what do you think?
Yeah, definitely.
Google, they have it open.
And it's actually, it's gotten a lot easier to develop for the Google Assistant.
But like Eric was saying, they don't really advertise out anything.
Whereas, you know, Alexa is like, they're just like reaching out for like anyone to develop.
Like they're really pushing it as something anyone can get into, which is really cool.
And then, yeah, Siri, I don't, I'm pretty sure they don't really even have that open or anything.
I've never heard of any third party Siri skills or whatever, which is pretty surprising just because they're, you know, they were the first to the space.
And I feel like they kind of maybe dropped the ball with that.
I totally agree.
There's no way they can't have some sort of programming API though, right?
Since they're going to have their HomePod thing.
And I just looked, Microsoft has the Cortana Skills Kit, which came out in September, but it's in public preview.
So, you know, that's also, I guess, a thing.
But they don't, their devices aren't really out yet.
Although there's some interesting places, I guess it shows up.
Yeah, I think Cortana, even though like the development kit's not really out there, I'm pretty sure they do have a good amount of like integrations with different services aren't strictly aimed at Cortana.
Right.
So that's kind of cool.
Yeah, they definitely are trying to integrate that into Azure and all their cloud stuff.
So let's maybe just go down the list of the hardware that's available.
So, you know, by way of contrast, like for Apple, I guess you have your phone.
You guess you have your Mac if you turn that on and you have this HomePod thing.
If you look at Alexa, I'll just go through the list kind of quick because there's tons of it.
There's the Echo, which is like this tall speaker thing.
There's Echo Plus, which is the same speaker, but is also a smart home hub.
There's Echo Show, which is like a touchscreen video type of version.
There's the Kinect, which will turn it into a landline.
There's the Echo Spot, which will let you make video calls and stuff.
That one's kind of cool.
It's got a little screen on it.
There's the Dot.
That's like the little mini one.
There's the Tap, the Look, the Fire TV.
And they actually are integrating them into cars as well, which is pretty cool.
So Ford Sync is coming out with Alexa integration.
So you can say, ask it for driving directions and playing music and stuff like that, which is cool.
And BMW and Mini are also integrating it as well for the 2018 models.
So that's just some of the devices that these skills run on, right?
I would also add to that.
So the Spot, so we're recording this on the 19th of December, and that's when the Spot will actually come out.
So I think outside of a few tech reviewers and on-site reviews, website reviewers, nobody has seen the Spot yet.
Yeah.
And then Show is kind of expensive.
So I would say mostly in the wild, you would see the Echo and the Echo Dot, especially if you're talking about cars.
There's a bunch of YouTube videos showing people how they fit like the Dot directly into the cup holder.
And that's kind of cute and neat.
And I know a bunch of my friends have done that.
That is really cool.
I've actually done that too.
I would do that if it wouldn't freak out my wife.
She doesn't like it around so much.
She's not...
We'll talk about the thing, constant listening, right?
But my car has four USB plugs, and it runs off USB.
It could just put it in one of those little cup holders.
It'd be awesome.
But no, it doesn't go in the car in my house, I'm afraid.
I guess we should make the distinction between Alexa and all those pieces of hardware I talked about.
So there's all this hardware, and then there's Alexa.
Dave, do you want to maybe talk about the two?
I mean, the hardware is really just the gateway to interact with the Alexa service.
And the primary kind of concept is this idea of an utterance or a user's intent.
So what is the user intending to try to do when they talk to the device?
I believe Amazon splits the technology up into at least two or three different services now in the back end.
That as a developer at scale, you could use individually for different things like voice recognition or text to speech.
So it's kind of like the front end and back end of the Alexa service.
But to the consumers, they really interact with just sort of the combination of all of that.
Right.
And can you take the Alexa AI piece, the software piece, and put it on your device?
It's like if I was on Kickstarter and making some smart bike that would, I don't know, turn on the blinkers when I would tell it to turn.
It's like, you know, whatever.
Something stupid.
Could I get that and plug it in?
Yeah.
A couple of folks have done some interesting projects like that.
A while back, I know one of the initial kind of popular hacks that appeared online was somebody taking a Teddy Ruxpin and making it speak and basically becoming kind of a conduit for Alexa.
And it was both exciting and creepy at the same time.
That's exactly how I imagined it would be.
There's still some videos on YouTube.
You can even use it piecemeal.
So if there are things where you wanted to build a service that did text-to-speech, you could use that portion.
If you just needed to deal with sort of understanding and matching with some confidence what the user's utterance was, they have that as a service as well.
That sounds pretty cool.
It's definitely some really neat services that they have.
And it seems like it makes it really easy to plug in your logic into their kind of text and sentiment understanding.
Yeah, and like most Amazon services, you can either use them as individual piecemeal kind of components or pull them together into a solution.
I guess one of the things I want to do is give people a sense of some of the skills that you can have on an Alexa device and then talk about ones that you have all either contributed to or worked on or something like that.
So let me just run down the list.
So there's over 20,000 Alexa skills now, which is pretty awesome.
It definitely seems like the place where developers are building new things compared to all these other places we talked about.
So you can have them for finance.
You can ask what your credit card balance is.
You can ask what the stock price is.
You've got if this, then that integration.
So if I get an email from this person that says this, put it on, edit them.
You can speak to it about all the if this, then that.
You basically integrate with that.
It integrates with like electric cars.
So I have a charge point charger from my car and I can ask it.
You've got to direct it towards the skill.
Right.
So you say like ask charge point how many miles were added last time when I charged or something like that.
So that's really cool.
Got smart home drinks.
You could ask it for like what cocktail you should have and how to make it.
Flash briefing, travel.
Like you could ask it where you could go for $400 or Lyft, all sorts of stuff.
Right.
Maybe go around each one of you.
Like what's your favorite skill?
Not sure what my favorite skill would be, but I've never published a skill to like the Alexa marketplace or whatever it's called.
But I've mainly just created like little personal ones for my own use.
Back before I found out about this project called Home Assistant, which basically connects different smart appliances.
I use Alexa to like control some lights and stuff.
And then for my old job, I would just ask Alexa to trigger like some scripts to run my computer like nightly.
Alexa, is my server up?
Alexa, am I still employed?
Exactly.
Yeah.
And then I also created the audio sample skills for the Flaskask repo, which we'll be talking about in a little bit.
And that was pretty fun.
Yeah.
I really like how Alexa allows you to stream audio, like good sized audio streams.
That makes it really cool.
Yeah.
I do a lot of listening to music on my Alexa.
It's cool.
Yeah.
Yeah, definitely.
How about your...
Yeah.
My favorite skill is my skill.
So I published several skills and the ones that are my favorite and certainly attract the most unique users per month is Seattle English Tutor.
So if you imagine, you know, just having this person or this assistant who would help you train your English skill, if English was your second language, which was my case, then that's what it is.
So actually, the first time I heard how Alexa operates and how, you know, see a few examples, this just springs to mind.
And of course, you know, this was also inspired by Mandy Chen.
So she was one of the earlier developers slash evangelist.
And she put out this beta and just kind of took it from there and published this skill and working on version two of that.
That's pretty exciting.
Very cool.
Dave?
It's a toss up.
So, you know, there's your favorite is usually the one you have published if you've got one published.
So I worked with Vermont Public Radio to help them basically create an Alexa skill that would allow users to stream their live streams as well as the episodic podcast content that they release.
Yeah, that's cool.
I'm thinking about doing that for the various podcasts, like especially around Python Bytes, because it's got all these little pieces.
And there's a lot of cool things you can do with audio because that's the native format of this thing, right?
It's quite awesome.
You can just kind of point the Alexa service at a stream and it can handle kind of starting and stopping and just kind of knowing a little bit where it left off.
Then you also had another one that got banned, right?
Yeah.
Like you were a rebel.
So this was when I first got my dot, it was almost a year ago.
It was about, I think it was Christmas last year.
The very first thing I did was make a skill that would interact with Twitter, go to Donald Trump's Twitter feed, grab a random tweet of his last, you know, 100 or 200, whatever is accessible via the API, and read it out loud.
So you could ask Alexa, you know, what's, you know, either his latest tweet or to ask Alexa to read a random one.
And it was almost always comical.
But after submitting it...
They wouldn't put it up there, huh?
No.
So they were running, this kind of goes back to the idea of Amazon having done a pretty good job in developer outreach.
They were offering a free Amazon hoodie or something like that.
If you got a skill published in the store before maybe January 10th or something like that.
And I submitted it and they rejected it because of copyright infringement, allegedly.
So I didn't know you could own your tweets, but that's sort of news to me.
My guess is they were just sort of afraid of the litigious Donald Trump at the time.
Yeah, it must be because that is the public thing.
And especially now, it's, you know, communication of the United States government in a sense.
So that, right, that's kind of in one sense, all ours, I guess.
I don't know.
It turned out I did some digging.
There were some already in the skill store.
They avoided using Trump's name.
So they said things like presidential tweets or something like that.
This portion of Talk Python to Me was brought to you by Datadog.
Datadog is a monitoring solution that provides deep visibility into your Python apps.
So you can understand why certain requests are slow or what caused a specific error.
Datadog's open source tracing client auto instruments popular libraries like Flask and Redis,
as well as async libraries like async.io.
So you can get started without making any code changes.
Within minutes, you'll be able to investigate bottlenecks in your code by exploring interactive flame graphs and rich dashboards.
Start a free trial to see for yourself.
As a bonus, Datadog will send you a free t-shirt.
Just visit talkpython.fm/Datadog for more details.
The certification process and all that is kind of evolving, just like everybody.
You know, they're kind of evolving as we go.
So if you put the name unofficial or like fan or fans of or whatever, then you get, not to guarantee it,
but you know, you get, you have an easier time getting it approved if it was, you know, something of that nature.
Okay.
Yeah.
That's good advice.
The president of the United States is not a matter, but yeah.
But just like normal companies, like fan of Disney of, you know, whatever it is.
So something like that.
Cool.
All right.
Well, let's talk about how you build these things.
So obviously Python is a good way to do it, which is pretty awesome.
And I guess the first thing people might wonder is, do they have to commit to going and buying an Echo device, piece of hardware, so that they can do this?
The answer is no.
It's like developing for Android apps.
You could use the simulator.
It's not as good as a real thing, but it's, it'll get you closer until you feel like you were committing, you feel like committing to a hardware purchase.
And of course the hardware is getting cheaper and cheaper and so on.
But, so the software that you could use is echo sim.io for the website to, you know, kind of click on it and then speak and just behave just like Alexa, except you can't do video stream, voice streaming.
So I don't know if you do podcasts and so on.
And another tool is your Revert mobile app that you could download and then behave just like Alexa.
That's like an iOS app, but then you can talk to it and it basically, it is an Alexa, but it's just a software one, huh?
Yeah, absolutely.
So it's like, you know, it's both Android and iOS as far as I know.
And so when you launch it, it just has this big dot, right?
Like the whole screen just filled with the dots and you click on it and then, you know, it listens for whatever input using your microphone and then, you know, dishes out the response that way.
And you link it to your Amazon account, of course.
Cool.
So one thing that I ran across getting ready for this show that I had seen a couple of years ago and I kind of forgot, but it seems so super helpful here is Ngrok.
Have any of you guys used Ngrok for this?
Yeah.
Ngrok is a great tool.
Tell people what it is.
It exposes a local port on your computer and basically tunnels, provides you a public URL that will tunnel traffic through that into your local port.
So if you're like developing a skill or some other type of application that needs to receive requests from the outside, you just fire up Ngrok and point it, give it the port you want to expose.
And then you get this temporary Ngrok.io URL.
And that's basically just the public URL that you get for free.
Yeah, that's really cool.
Because one of the reasons you need that is you basically have two choices when you set up an Alexa skill.
There's as you go through the Amazon dashboard.
And one of them is where do we invoke this, the logic of your skill?
And it could either be an AWS Lambda, which is the serverless computing thing, which you can definitely do in Python, or it could be some HTTP endpoint.
And so if you want to do like a dev version testing on your machine, you can run, say, like Flask or Flask Ask, for example, on localhost on a certain port.
And then you can use Ngrok to map that localhost only port out to Ngrok.com, IO, whatever it is.
And then that becomes a public HTTPS URL that you can tell Amazon is how to get to it.
And it actually hits your dev server.
I guess you could even like have breakpoints and all sorts of crazy stuff when you talk to Alexa, right?
I think for Ngrok, the free version, because I actually look into Ngrok for not for Alexa skills, but for my day job.
So I think for the free version, you could have your familiar ports when you launch.
And if you pay, I think, $10 a month, you get two reserved ports.
And you could even use custom domains for you to fix them when you launched Ngrok.
So but yeah, you know, if you don't use Ngrok, I guess let's just say you have your own HTTP server, you have to worry about like certs, and you have to worry about trusting issues and so on.
So Ngrok, it's kind of what I've seen people do if they don't use Lambda and use your own server.
Okay, that makes a lot of sense.
All right.
So I guess, Eric, I'll stick with you for a sec.
What do you use when you're writing these skills?
Like what's the tech stack look like?
I just use the, I think other people would echo this, the front part, like the interaction with Alexa to resolve whatever your voice stream is into an intent.
There's no other way than to just using their templates, using the ask Alexa skill kit.
And then like you mentioned, I use the triggering for Alexa as the input to trigger my Lambda function.
And then Lambda function, if I need a database, I use DynamoDB.
And that's kind of the whole flow.
Yeah, that's pretty cool.
And DynamoDB is a really interesting NoSQL as a service inside AWS, which is cool.
Yeah, super fast.
Yeah, it's crazy fast.
That's cool.
Cam, how about you?
Yeah, so I don't use Lambda or AWS or anything.
I just typically, since I haven't published, it's usually just through NCROC.
But I write all the code using Flaskask.
And then once I'm ready to kind of just have that running, I host it on Heroku, just like the free tier.
So it's kind of just two steps.
Yeah, that's nice and easy.
Yeah.
We'll definitely, we'll talk more about Flaskask in just a second.
Dave, how about yourself?
Yeah, it's Flaskask in Heroku.
And with Heroku, the free tier for most skills, especially if it's sort of just a personal skill, and you don't expect it to become like a top 10 skill in the skill store, you can pretty much run the free tier indefinitely.
I can imagine like how much traffic could Alexa possibly generate?
That's sort of the good thing is that it's very kind of quick in the interactions.
And even if you're doing something with audio and audio directives and opening a stream, the stream actually goes from the stream source to Amazon and then to the endpoint, whether it's a dot or something else.
So you don't have to worry about it.
You don't have to flow it.
Yeah.
You don't have to pass that through.
Yeah, that makes it really nice.
Yeah.
So your Heroku instance or something else could spin down for a while.
That stream could play for a half hour.
The user might then pause it or stop it.
And then you'll get the call to your server from Amazon saying that the user stopped the stream.
Yeah.
So it seems like a lot of stateless, really quick, short type of things.
Yep, definitely.
And that's sort of the catch is the stateless part is that this is probably getting a little too far ahead.
But I mean, that's really the hardest part in dealing with the skill development is that Amazon assumes you're going to wrangle all the statefulness.
Right.
And that might be why you might want a database, for example, like Eric was saying.
Right.
More or less push the session into the database.
The next request comes in from that user and you can like kind of infer where you might want to pick up again.
Because it's not like normal web application development where you might have a cookie or a session or something.
And then all this middleware you can use, it'll automatically pick that up.
What do you use to trigger off of to identify the user?
Do you have their account, their device ID, something like that?
From my experience, there are a couple different things.
And they change based on basically what part of the Alexa skills API you're using.
For things like audio, it's once the user actually starts a stream and they start hearing audio on their Echo device, it actually closes the session.
So your session that you might be tracking with a session ID actually is no longer.
When that user, that same user issues a stop or a pause or a skip, it'll look like a brand new request to your Echo application in Heroku, for instance.
So there's like a special, I believe, context ID.
This is an area I actually caused me to give a whole 45-minute talk at a local Burlington Python meetup here around the oddities of this.
But for a while, there's even discrepancies in Amazon's only.
I don't believe so, unfortunately.
All my materials are online.
Okay.
We haven't been recording them.
But Amazon's documentation was also kind of incorrect.
And for those who had been doing skill development maybe for a while or kind of tried their hand at it like a year ago, if you tried to do any of the audio stuff with Amazon's actual formal test suite that they have in their developer web app, it didn't work because it didn't have this proper kind of unique context ID generation.
So you just have to hold on to that, and then you need to hold on to the stream ID.
There are certain things you can give to Amazon saying, you know, if you're doing a dialogue with a user and you're not closing the session, the user chooses, I think, you know, common example skills or like pick your, tell me your favorite color.
And then you use that later on in the conversation.
Amazon can hold that session-based information.
But once you start playing a stream, the session's gone.
So it's on you to have a caching layer or a database that says, okay, for this particular interaction, they started this stream.
So that way, when you get the stop or the pause or the skip, you know what it refers to.
Okay.
Yeah, that's cool.
It sounds challenging, but you can make it work.
It's one of the newer areas for playing streams.
So from day one, you always get the user ID and the session ID.
So the session ID obviously just, you know, as good as the session goes.
And the user ID is what, it's a string that associated with your Amazon account.
So say if you use have multiple like Echo and Echo Dot, you will get the same user ID for both devices when they launch the same skill.
So later on, I think you face a challenge.
If you want to differentiate between Echo and Echo Dot, then you want to use the, there's a newer checkbox to say, ask for a user's locale.
And if you do that, then you actually get past the device ID.
And that's how you get by for identifying unique devices versus just the user ID.
Right.
If you have like one in your kitchen and one in the living room and the kids are messing with it in the living room and you're in the kitchen, right?
Like, yeah.
You might want to differentiate between those.
There are instances that you want to have a frictionless experience between, you know, different devices that you have as long as you have the same ID.
Like say, for example, if you enable a skill set, you know, for your one device, then you automatically enable it because it's associated to your Amazon account.
But there are other times when you need to differentiate between devices because of device limitation.
You know, for example, you know, Echo Show will show you a little screen and while the Echo itself doesn't.
So there are different use cases for them.
And because this is so new and Amazon's learning as we go, they definitely try to iterate based on that.
And one thing that I would kind of just stand my soapbox and sing the praises for Amazon is they do listen to developers, arguably more so than Apple and Google and all the other platforms.
That's how I feel about it.
That's pretty cool.
So let's talk about what Dave and Cam have brought up, this thing called Flask Ask.
So Flask Ask is, is that the ASK, Alexa Skill Kit is what the ask stands for?
Right.
Okay, cool.
So Cam, tell us what Flask Ask is.
It's a Flask extension.
It's made by this guy, John Wheeler.
And it's a really cool Python package to get started with Alexa.
Basically, he created, he provides some decorators with Flask.
You know, you would route your view functions with at app.route.
You do the same thing, but it's with like ask.
And then you basically just write your code as if you're doing typical Flask web app.
You just have your view function.
And when you return your response, it provides special response classes to either ask or tell the user.
So you can like ask something and then expect a response back to that question.
Or you can just send a message to the user.
And it just makes it really simple to get going.
And I've seen that it's pretty cool.
It's brought in a lot of people who are new to Python or programming in general or just diving in, which is pretty good for the Python ecosystem.
A lot of people know Flask or they know some Python web framework, which is super similar to Flask in a way or another.
And if you can just write a Flask app and instead of put, you know, the view decorator or whatever, the route decorator, you can just say at ask.intent.
And name basically the intents of your app, which is pretty cool.
So it seems like it's really, really approachable.
Dave, what would you add to it?
It adds templating as well for the dialogues and the interactions with the user.
I know what templating looks like in the website.
Like that's the HTML.
But what does that mean in the context of a voice assistant?
It's extremely similar.
So you can define your basically the spoken portion of Alexa when she talks back to you.
She or it or whatever you want to call it.
And you can also use different pluggable variables as well.
So it's sort of like if you were building a web application with Flask or Django or any of the other Python frameworks.
They typically have some sort of templating engine where you can write your HTML, but then have some programmatic logic in there and do some dynamic substitution when it renders it.
You can do the same thing with the spoken responses back.
So it makes it a lot easier because the big nicety of Flask ask, other than it fits right into the kind of the Flask model of building web applications,
is that it also deals with wrangling all the nasty JSON that you need to send back to Alexa.
Yeah, that's pretty awesome that you can kind of forget about that.
Yeah, you can take Flask ask.
You can be up and running and never have to really, you have to know a little bit about the sort of how the API works with the idea of the requests and the responses.
But you don't need to know the JSON format, which is pretty lengthy.
The templating and the stuff for the responses, what's also cool is it also allows for SSML.
So you can kind of give like the actual voice response some more kind of customization.
Yeah, like the inflections, the way you can kind of tailor how things are pronounced.
So it's not as robotic.
Yeah, that's cool.
So you can make it sound like it's a question like go to the store versus go to the store.
Yeah, I think some of that Amazon does pretty well by default.
But for, you know, if you have the name of a product or something, I had a heck of a time with the Vermont Public Radio skills, just making it sound kind of conversational.
I can imagine.
A good thing for SSML is besides, you know, like you want to change the default behavior.
Like if you want to, instead of say cat, you want to spell out the C-A-T.
That's where you invoke your SSML.
They also have a bunch of what they call the speechlets.
So that when you want to add more speechlets, but you don't want to worry about like encoding your audio into a specific format that Amazon likes.
So, for example, you could have SSML go, wow, or like, hey, you just open a door, making a door sound like that kind of door sound if you want to play like a voice game.
And that's exactly what you use SSML for.
You just use a little tag, like XML tag, and then you find out the list of ever-growing list of speechlets that they have.
And then you could start having interactions that way without worrying.
Like I said, like the biggest challenge for encoding your own audio for Amazon is the bunch of restrictions that they place to just because for their consideration and for a speed of getting that file and play back.
For voice, you don't have the luxury of visual.
So you always have to short, concise, and fast.
So that's kind of cool that they have these, you know, I would say about 30 speechlets.
And of course, they're adding in more every day.
That sounds really cool.
One of the things you made me think of when you're talking about your door and stuff is you could do a pretty awesome audio replacement of like a text-based game, right?
You walk into the room and you see this.
What do you want to do?
Like all those types of games like Leisure Shoot Larry or The Muds or whatever.
You could probably have a really awesome little skill that is like that game, right?
That is exactly the example they give.
So if you have gone through some of the later, not the beginning, but the later like Amazon workshops and stuff, and that is exactly the example that will walk you through.
And the JSON example, I'm sorry, the JavaScript example that they give online that they publish open source is the game that you interact with people and especially kids.
They don't have a lot of patience and they don't have a lot of white vocabularies.
So they use that as an example.
So, you know, you open up a box and do you either take a look at it or you close it right away?
And then you wait for the kids to respond and then you'll go from there.
So you have all these, you know, interactions that, like you said, the gaming aspect of it.
That sounds pretty fun.
You know, with this Flask ask thing, it makes it so much sense, like where ngrok fits in.
So basically you write your code as a Flask application, which, you know, you can run.
It's going to run on localhost on port 5000.
But then in order to actually test and develop and debug that, you need to be able to let Amazon services directly call that service, right?
Right.
You can do some local testing because it is a Flask application.
I see.
So if you know what to send, what to expect, you can like send it that over and over just through like Postman or a unit test or something, right?
Exactly.
And you can do it programmatically in your unit tests and you can always look at the response that comes back.
But I mean, from my experience, nothing, if you're going to submit something and not use it just for personal use, nothing beats actually using a hardware device.
Cool. Is there a way to make like personal skills that your Alexa has that are not public?
It's like associated with your Amazon account.
Like, I think it's in development or something.
That's what the skill is marked as.
But do you guys know if that like persists or is there like a limit to how long you can keep it like running privately?
I don't think there's a limit because I definitely have some old ones lingering that I haven't cleared out.
Until Lambda starts to charge money, I would just keep all of my skills.
And so you could, you know, for sure, you know, keep a skill in development.
And I think more recently, I don't know how long it's been, but definitely more recent than day one is that you could start inviting your people to, you know, beta test that skill set.
So you have their Amazon, I think you either you get their email address associated with their Amazon account.
And then you could submit it to, you know, a little page or portal to say, I want to have, you know, my code test, beta test my skill.
So that way I could share that skill without having to publish it in the marketplace.
That's pretty cool.
I can just imagine you might want to automate some stuff for you, but it's too specific.
Yeah.
Once my grandma started turning on my living room lights, I would just like cut her off.
Right.
That's right.
Like if my robot lawnmower finishes and then goes in the garage, first open the garage.
And when it's in the garage, close the garage and then turn on the sprinklers.
Like that's probably not a skill everyone wants, but that'd be really cool to say.
Go mow the yard and then water it.
You know, what's super creepy is that for the new Amazon show, you actually have a drop-in mode.
So they could actually call you like a Skype call with video without you knowing.
I think you could, it has to be opt-in.
But if you have two shows blown to the same account, you can actually do that drop-in thing.
And which is just super creepy.
I mean, it's almost up there as Amazon keys, but you know, that's another story.
Another day.
Yeah.
The Amazon keys, where you basically give Amazon a key for the delivery people.
Interesting.
Two, third-party contractors for Amazon as well.
That's right.
Not even Amazon.
Yeah, exactly.
But anyways.
Quite interesting.
Yeah.
That's a whole nother level.
So Dave and Cam, you guys both contributed various things.
Cam, let's start with you.
What do you do for Flask Ask?
Yeah.
So Flask was like my first real step into the open source world.
I started by just going through the code base and trying to document everything.
Or like the doc strings and everything.
And that kind of just gave me a really good understanding of how the whole thing worked.
And then at the time, there was no support for audio streaming besides through SSML, which is, it's limited to like, I don't know, 30 seconds or a minute or something.
And once Amazon announced like basically the audio streaming capability, I implemented the, basically the response classes for streaming like audio streams from some URL.
So that you just say return audio and then whatever.
Dave came along later and really made that much more solid for working across with that whole session issue here speaking of.
Yeah, cool.
And Dave, how about you?
I basically built off of a lot of the groundwork that Cam had laid.
So I had, I found Flask Ask when I first started doing skill development.
And I used it as the basis for the streaming skill for Vermont Public Radio.
And everything was working great.
And we went and pushed out kind of a testable version into Heroku.
And as we were manually testing it, we found that every once in a while, the stream would just sort of get interrupted or stop.
After some debugging, I found out that it was because with running it in Gunicorn.
I never know how to pronounce it.
It had multiple sort of workers.
And one worker would retreat or respond to a request from Amazon.
And then the other one would.
And they didn't have any sort of shared state.
They were just using kind of thread local storage.
I think that's basically what the default behavior was at the time.
So I had to find a way to get them to use some shared state to be able to solve the problem of starting and stopping the streams.
And luckily, all it required was digging into sort of work sub, the underlying kind of underpinnings of Flask, figuring out how that worked.
And conveniently, there was a caching layer already there.
So it was a matter of just kind of bringing that up into the Flask ask world, making it simpler.
Yeah, that's cool.
Using the simple cache, I think, is the actual name.
So it's as simple as that, where it'll do it in memory.
And that solved the streaming problem.
Let's say push across the different request threads, right?
Right.
Because you can never guarantee who's going to respond to it.
And if you did spin up multiple, let's say you did have a massively popular skill, or maybe your skill is actually part of a larger application.
It also just happens to be an Alexa skill endpoint.
You might not even know which server responds to it.
Interesting.
So something that's similar to this that you created, Cam, is called Flask Assistant.
All right.
Tell people quickly about that.
Yeah, it's basically just the Flask ask for Google Assistant.
And rather than using the Alexa Skills Kit and basically the whole Amazon ecosystem, it uses something called Dialogflow, which used to be called API.ai.
And what that is, is basically a NLP, a natural language processing platform owned by Google.
And so it's pretty analogous to Flask ask.
It's got a very similar API and everything and allows you to integrate your, it's not called a skill for Google Assistant or API.ai, but basically your little voice app with things like Google Assistant or Skype or Facebook Messenger.
Do they have to run in different processes?
Or could I host both a Flask Assistant and Flask ask app in the same code on the same server?
I actually haven't tried that, but it should be possible just by basically stacking decorators.
And then one cool thing about Dialogflow is that Alexa is actually one of the integrations.
So if you were to do it that way, you could basically export your project into the Alexa Skills Kit.
But I mean, if you're going to do that, it makes more sense to just use Flask ask since it's...
Right.
Yeah.
And maybe you just run two processes on two different ports or whatever.
But yeah, it's still pretty cool.
Yeah.
It's been fun working on that.
We're getting sort of near the end of our time together.
Let's talk about maybe a few higher level questions.
First, maybe Eric, you can go with this one first.
How do you make money as an Alexa developer?
So if I was working on an iPhone app, an iPhone game, I know how I make money there.
Or Android, just not as much per user.
But still, you put it in the store, people buy it.
You don't buy these skills.
You just tell Alexa to install them or you go to your phone and install them, right?
Yeah, that was my question from day one.
It's like, how do you make money from it?
And so they recently announced an in-app purchase.
So essentially, you could make purchase just very much like what you do in an iPhone app.
But I haven't...
Because it's so new, I don't know the details on that.
But currently, you have two ways to make money.
Well, three ways, I guess.
So one is you could get Alexa credits, AWS credits if your Alexa skill invoke charges.
But since I tie my end to Lambda, and currently the first million calls per month in Lambda is free.
So basically, it's $100 per month and it's month-to-month basis.
So I basically just use that to fund my other AWS usage.
So that's pretty cool.
And the second way that you can make money is you could be a top skill.
I've seen people who post on their Twitter tweets that they've made like $1,100 per month of being top skills.
But I don't know what the selection criteria is.
So I can't say for sure like how to do it or how not to do it, what gets you there.
But that's certainly another way that they've announced and you can make money from it.
And the third way is basically just use Alexa as a front end for your voice user interface.
And you tie that into external account.
And that's what the majority of the companies are doing, whether it's public radio, maybe they do charge people.
I'm sure in this case they don't, but for Vermont, public radio.
But like say Uber, for example, right?
Then you use Alexa to order your Uber rides or Domino's Pizza, which is a US pizza chain that you could use that to order pizza.
And tie into your account.
And then that you make money that would increase your usage.
That's a third way.
Right.
It's just a funnel, right?
To an existing business model.
Yeah.
Exactly.
And I don't know.
I don't think there's any studies.
I'm sure Amazon's more than happy to tell you how much increase of usage that, you know, people increase their, you know, monthly spending on Uber or Domino's Pizza by 20% just by having your Alexa skill or whatnot.
But I haven't seen any studies like that.
So I can't say for sure.
But the third way seems to be most common for business today outside of just hobbyists or some other companies.
Yeah.
Right.
I mean, Dave, that sounds more like what you're doing.
I know public radio doesn't necessarily directly make money, but increasing listenership is a key goal, right?
Right.
There's sort of two sides to this.
One is being able to engage.
In this case, since it's Vermont Public Radio, it's engaging listeners and building awareness and also helping drive contributions during fundraisers.
So obviously having the ability, you're using the stream.
So you're delivering your product.
In this case, they're live content and they're episodic content.
And in doing so, they also have the ability to advertise and promote their own offerings.
So that's sort of one approach where it's sort of more of a marketing channel.
And I think in what Eric was saying is really sort of what I describe as like the post-walled garden economy where you no longer get rich in the app store within the walled garden.
You really have to use it as a way to accelerate your business model outside of it and just meet the customer where they are.
You know, if they're in their kitchen and they're trying to cut vegetables and corral a kid with one arm, being able to have the conversation with them over Alexa is sort of the way to meet them in their time of need.
That's pretty awesome.
The other thing that I think we're touching on is these devices, except for mine when I just turned off the microphone so we could actually have this without being interrupted.
Are you sure, Michael?
I mean, that's a good question, right?
These things are generally always listening to us, but maybe they don't process everything we're listening.
Maybe they don't share everything we're listening.
But Cam, maybe you start first.
What are your thoughts on the privacy around always listening devices?
When you get one of these devices, you just got to be aware of that and personally be okay with it.
I'm not sure if Alexa provides this, but I know with the Google Home, you can go to your account activity and see and listen to everything that it has recorded.
And I know you can delete that.
I'm not sure if Amazon is as transparent, but I think it's just something you got to accept if you're going to buy one of these.
Yeah.
Eric, what do you think?
I think the answer is yes.
So I know I have been going into my Amazon or the Alexa app and listening to what Alexa knows about me and deleting the voice bits and so on.
But of course, you know, this is a big topic and it's been the news recently just because of the murder case.
I forgot which state it was in.
Basically, you know, you could go, we'll probably include it in the show notes or whatnot.
But so I actually went out and looked at the official response from Amazon regarding this.
You'd never know, like, how much do you trust Amazon, right?
Back to the Amazon key issue.
But the official word is that they do a one second buffering to detect your wake word.
And then they constantly delete that one second buffering.
So unless you hear one of the wake words in today's setting is one of the four, right?
You could choose to have Alexa, Amazon, computer or Echo as your wake word.
So they do that one second thing to do echo cancellation and they do to detect false positives.
But the wake word and then only if you speak the wake word, then you start recording and so on.
Obviously, like you did, Michael, is to put on the mute button when you really don't want anything to, when you don't want Echo or Alexa to participate anything.
Yeah.
And Dave, what do you think?
I've really got two sides to this.
One is I'm less concerned about what Amazon or somebody else is hearing.
But I do like to play around with it because I'll use funny voices.
Like even with Comcast, they now have like voice control and the remotes.
And I just try to see how good it can recognize the weirdest voice it can come up with.
And it's shockingly good.
And if they want to record that, feel free.
They can keep that on a server somewhere.
I'm more concerned about sort of the secondary kind of proliferation of all the connected things that people are going to run out and buy and plug into this ecosystem.
Because, you know, you look at, you know, the smart home things, even just a smart home outlet.
That was like the big thing.
I know my family went out and bought last year when we all got Echo Dots.
Usually you have to sign up for a third party service or something from that consumer electronics manufacturer who's not skilled at securing a software based environment.
Yeah.
And that's what integrates with Amazon.
So I'm less concerned about Amazon and more concerned about all these kind of secondary vendors that are going to do a poor job and they're just going to create these holes in our homes.
Because, I mean, Amazon actually is pretty good at making sure even the media that you play, like the streams and everything, are done through a kind of, it's kind of annoying.
But it has to be a, I believe, a TLS based encrypted connection and it has to have the appropriate headers in the communication.
So it's hard to, you know, even get media to play in an unsecure way via the Echo devices.
Yeah, that's a good point.
I definitely think the Internet of Things is, the cheaper the device, the more likely you're going to have trouble with it exposing you to things.
As somebody who deals with DDoS the whole time, right?
Like, so, so like, I mean, we do thread Intel and, you know, like the, of course, the Mariah botnet that you heard about last year was all on IoT devices and so on.
So this is a big concern, you know, instead of being an infected host with, you know, something that the user look at every day, it's now becoming all these unmanaged, relatively powerful devices that spread around like monitoring temperatures, right?
Yeah, like, aside from just, you know, the things you talk about, like, as this all progresses with all these different smart sensors, like, either activating or deactivating based on your, like, daily routine, whatever entity is, like, in control of all this, all this information, they can build, like, a really good picture of what your life is like, just by all these small little adjustments you make with your smart appliances and stuff, you know?
Like, they can tell when you're home or, like, when you cook and all these things.
So it's something to be aware of.
Yeah.
How many people live in your house based on how many unique voices does it hear, for example?
But remember, it's, as they said, I think it was the NSA after the whole Edward Snowden thing.
It's just metadata.
What are they going to do with it?
That's right.
It's just metadata.
Come on.
No problem.
I don't see how that could go.
Right.
All right.
Very cool.
Even all that stuff said, it sounds like most of us, maybe all of us, have some kind of Alexa device that's generally on or more or less okay with it, at least in limited parts of our life.
Yeah.
For me, at least it is.
Yeah.
I don't have any smart appliances outside of, I've tried them and then I unplug them just to see how they work, but then I don't use them on a daily basis.
Yeah.
And I've got my Alexas in both the first and second floor here and use them daily.
They're really, really nice.
All right.
Well, I guess we're pretty much out of time, so I'll have to leave it there for the Alexa stuff.
But let's go down the two questions.
So Dave, we'll go with you first.
Favorite editor?
I can't make up my mind.
I either use Vim or Emacs, depending on the situation.
And my hands are in constant pain as a result.
Cam?
Sublime.
It's just so quick and nice.
And Eric, have I corrupted you?
Yes, you have.
So I used to use Vim, but then since I listened to Talk Python too much, and so I now use PyCharm exclusively.
I definitely love that.
All right.
And Eric, keep going with you.
How about a notable PyPI package?
Yeah.
So I like requests.
Of course, as half of the people here, I think that it should be in the standard library.
And if Ansible counts, then that's definitely what I would like as well.
The library slash packages.
Yeah, I think it does.
That's cool.
Ansible.
All right, Cam?
So aside from Flaskask and Flask Assistant, if anyone's interested in making their own
skills or anything, or just not even skills, but just programs to control things within their
house, I would check out Home Assistant.
It's a really cool project.
It's a very cool project.
It controls so many devices.
It's a really cool on-your-own-network website.
And yeah, I had the guys on on episode 122 a while back, so definitely cool.
Dave?
You can't beat requests.
I was going to say that.
Yeah, awesome.
Okay, so I agree.
Request is definitely the most popular one on the show and out in the world.
Final call to action.
People want to get started.
They want to get started with Alexa.
They want to get started with Flaskask, things like that.
What do they do?
Just jump in, you guys.
Yeah, I think they could just go.
There's a bunch of templates, pre-made templates and step-by-step guide.
Like I said, Amazon's very involved in reaching out to potential developers.
So you could easily get a lot of freebies that way if you publish your skill sets.
Go check out some of the tutorials for Flaskask and get started.
It's not too hard.
There's a bunch of sample projects, each one of them.
I did some work in making sure that they're sort of sanity checked with each version.
So they should actually work.
And they'll show you how to use things like Flask Blueprints with Flaskask.
They basically recreate some of the traditional Alexa skill kit demo applications as well.
Well, it sounds really fun.
And I'm definitely looking forward to building something that I can talk to Alexa about.
I'm just not sure what yet.
Thanks for being on the show, everyone.
Awesome.
Thank you.
Yeah, thank you.
Yep.
Bye.
This has been another episode of Talk Python to Me.
Today's guests were Eric Cho, Dave Botella, and Cam Sweeney.
And this episode has been brought to you by Datadog and us at Talk Python Training.
Datadog gives you visibility into the whole system running your code.
Visit talkpython.fm/datadog and see what you've been missing.
Don't even throw in a free t-shirt for doing the tutorial.
Are you or a colleague trying to learn Python?
Have you tried books and videos that just left you bored by covering topics point by point?
Well, check out my online course, Python Jumpstart, by building 10 apps at talkpython.fm/course
to experience a more engaging way to learn Python.
And if you're looking for something a little more advanced, try my Write Pythonic Code course
at talkpython.fm/pythonic.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, Google Play feed at /play, and
direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.
Thank you.