Back in May of 2018, Bob Belderbos, Julian Sequira, and I started what would turn out to be a nine-month
project. We wanted to create a dedicated 100 days of code course specifically for Python web
developers. Much of what we created for that course, we did have prior experience with,
but with that many different topics, much of it was also new to us. On this episode,
we teamed up to distill the lessons, tips, and tools we found interesting on that journey into
a quick list of cool tips and techniques. We hope you find something new and useful.
This is Talk Python to Me, episode 224, recorded July 29th, 2019.
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 at,
M. Kennedy. 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 Ting and Linode. Please check
out what they're offering during their segments. It really helps support the show. Bob Julian,
welcome back to Talk Python to Me.
Thank you.
Good to be here, Mike.
Nice to be here.
Yeah, it's good to have you both here. We kicked off our acquaintanceship way back. I can't remember
which episode it was. It was quite a while ago when we talked about this 100 Days of Code project
and journey that you all had been on. And actually, it's turned out to be quite the journey from there
as well, right?
Oh, yeah. Just nonstop. I think it was episode 140 as well.
Yes, it was 140. Thank you.
100 Days Survivors. It was quite a hardship.
Yeah. So, back then, you guys had been going through 100 Days of Code and documenting it and
blogging about it. And then, you know, you came on the show to talk about it. And after that show,
we were sitting around talking like, you know, this is really cool. There's not a whole lot to support
people specifically in Python to do it. So, you guys and I, we all teamed up to write the 100 Days
of Code course that we released last year. And that was really fun and people seemed to like it. So,
we wrote the 100 Days of Web in Python course. And that was quite the journey as well and recently
released that. So, this show is going to be based on stuff that we take from those experiences.
And I want to be clear. I don't want this to be just like an infomercial about the course. I want
us really just to focus on the technology. But when we created these courses, this is like,
it took us nine months to write that 100 Days of Web course. And some of that was just the effort of
recording. But a lot of it was research and polishing ideas and like understanding things better,
right?
Oh, without a doubt. The amount of tech that and skill that I had to develop in order to teach it
was insane. There were so many topics that I just, I knew a tiny bit about, but not enough to actually
build something usable and something I could teach. So, yeah, a lot of that time, I would say 80% of that
time was actually learning and trying to figure stuff out.
Yeah.
Bob?
And there were some very big topics like JavaScript and Django. And we had to break them down in four
day segments, which was a challenge in itself.
Yeah. Well, I think part of the challenge of anything like this, and especially the web,
is I don't really know when this tipping point occurred, but it felt to me like for quite a while,
it was pretty straightforward. There were some choices you had to make if you wanted to write
a web app in Python. Like, am I going to use Django? I'm going to use Flask. Maybe I'm going to use Pyramid
like Michael. I really like that framework still. And now, now you look at the list of like new and
upcoming frameworks. There's like a new web framework every month, at least. It's crazy. So, you know,
it's not a surprise that we don't know all these off the top of our head because it's hard to keep up
with all of them. And then there's always the, well, that's only been out for a month. Like if I learn it,
is it going to actually be around like two months from now? Right. So it's, there's just,
do you guys get the sense that the web is kind of blown up? And then, you know, that's only the
Python framework, right? We've got JavaScript, we've got databases, we've got like, there's a lot
of axes on which that happens. That's exactly right. I hit the, I actually hit that issue recently at
work where, you know, I'm trying to create a web app, but did I use Flask or was I going to use,
you know, Django? And then wait, what sort of interaction did I need on there? What sort of
JavaScript do I need to learn? Oh, wait, do I need jQuery? You know, it just, the list went on,
you know, how am I going to deploy it? Is it going to be a static site? And yeah, it's just,
it's ridiculous, but it means there's a lot of fun to be had. That's right. There's a ton of fun to be
had. And so when we went through this course, we all learned a bunch of stuff. And basically it's made
up of roughly 24 four day little projects. And each one of them is generally a separate technology and
generally standalone. And I said, I don't want this to be an epimertial about the course. So I want to
really point out that this is all, every bit of this is, we're going to talk about is in a GitHub
repository. And each section has its own little bit with its own readme. So if you want to go play with
that, the GitHub repo is open and free. And we'll talk about like where each one of these topics lives
in the GitHub repo. And I'll be sure to put that in the show notes as well. So with that in mind, Bob,
you want to kick us off with the first topic that you got out of the course that you think is
interesting for Python web devs? Yeah, sure. And I start right off the bat with APIs and API star.
It's by the same author of Django rest. So I chose that framework as it's relatively new. And knowing
the author, I expected to have sensible defaults. And it had was a fun little project that makes it very
easy to build your APIs. I got pretty quick results. I also needed some test data for which I used
Macaroo, which is a service or website that makes it very easy to get fake data. And combining the two,
yeah, became an interesting project where I think I use some car data and build an API around it.
One of the challenges though, that I saw when we deployed the app is that there were some breaking
changes. So yeah, one warning when you use top notch open source off the shelf products that they might
change and they might change rapidly. So I think in the end, we had to pin the version in the requirements.
So to make sure that people weren't hitting those issues.
Absolutely. And API star is really cool. It's by Tom Christie. And it has changed a lot, actually,
even since, since we wrote the course. And that's, you know, that's just the way the way it goes.
That's what I was sort of hinting at not specifically thinking of API star, but there's a ton of these
projects that are like that. And, you know, I think it's good to do like a survey of all them out there. But it's
also challenging to figure out which one is going to gain the popularity and energy because they ebb and
flow. But yeah, it's really interesting. I love this the way that it works. One of the things that you introduced
me to here that I found super interesting is a great service for fake data. Because, you know, as a course
developer and trainer, having fake data is awesome, because you don't want to use real data, but you want to have
realistic data. But, you know, there's not that many trainers or course developers, right? But almost everyone has to have a
prototype app. And you often have to build the app before you have the data, because the app is going to collect the
data, right? And so in order to build out the UI and the API and all that stuff, it's really good to have
realistic data. So tell us about this place where you got the data from on that.
Yeah, it's muckerrule.com. And it has 143 data types, as we speak. And it's broken down in location,
commerce, advanced, personal, and the VIN number. And yeah, you just pop them in the field names,
and then you can download it in CSV, JSON, tab limited, SQL, Cassandra, Firebase, Excel, XML, like all
these useful data formats. And it generates a file. And then yeah, you can just load it in and start
using it. It's really cool.
Yeah, you named off some data types. And one of them was like car VIN, vehicle identification number.
And that's like this big, long, specific thing. But it literally generates reasonably valid looking
VIN numbers, not just random values there, but like actually what you would expect in terms of
number of character. Yes, exactly. And it has that stuff for like medical bits. And like,
it's really quite interesting, all the data sources that it pulled from.
Yeah, indeed. And if I look at the API class, then that literally translates to the data. So I have a car
class with ID, manufacturer, model, year, and VIN. So it made it relatively easy to build an API on top of
it. Yeah, that's cool. So if you're out there building something, and you need data for your API
or web app or whatever, Macro, that's pretty cool. And one thing I also wanted to highlight in this
section is PostPen. It's a GUI to test your API. So that's another thing. I used it before, but I guess
I became better at it because I had to use it again. And yeah, it's very convenient to test your API and
get and post requests from GUI. Yeah, you can do it from your dev tools. But Postman is so nice. It lets
you set the headers just right. It lets you do all the ACP verbs, you know, post, delete, things like
that. For Talk Python, I have a whole suite of APIs I have to maintain for most of the courses. And I have
a whole like segment of saved like development and production stuff in Postman for testing that and
make sure it all works. And yeah, I definitely recommend Postman as well. Yeah, awesome. All
right, Julian, you want to talk about this next one? Like I'm really excited about that. I just can't
believe how much we get out of this next one here. Okay, so I'm really excited about this one. This is
Netlify. Sounds a bit like Netflix, but it's Netlify. It was a static site generating deployment
website. It's just like a jack of all trades. I absolutely loved it. And the funny thing is,
as we touched on before, I knew nothing about this. I didn't even know it existed before this course.
As we were planning the course, you showed me this, Mike. You said, hey, if you're doing something on
static sites, check this out. Yeah, originally your goal was to just cover static sites. And like,
what do you use, Pelican or something like this? Yeah, Pelican. Yeah, that's right. And I go,
if you're doing Pelican, you got to check out Netlify because that looks super interesting.
And I thought, oh, what is this? What's this thing Mike's pointing me to? And when I went and checked
it out and actually had a go, it was fantastic. So to give anyone who's listening the general overview
is it's this amazing tool where you write your static site in GitHub as you normally would or whatever.
And once you have it built in there using Pelican or Jekyll or Hugo or whatever else you want to use,
you then point Netlify at your GitHub repo. So there is a little hook in there that
links into your repo and it just monitors your repo. It's this continuous delivery or continuous deployment
type tool where once it detects a change in your GitHub repo, it'll build your site for you
and deploy it on the net for you. So just completely hands off. You don't have to do a thing. And that was
probably one of the most satisfying parts of the course was when I was demonstrating that or recording it.
There was that moment of fear where I thought, oh, is it going to work? Please work. And then it just worked.
So as I'm recording, I generated the site. I pushed my GitHub code to GitHub and then it actually created the site within a minute.
And yeah, it's just, it's live up on the net. They give you a free URL.
So it's obviously some garbled rubbish that's your URL and you can obviously then go and purchase your own domain and add all that in.
That's all extra. But from a free base standpoint, you can run your static website on the net using Netlify.
And it was really cool. I really enjoyed it.
Yeah. It seems like just such a nice way to do things. To me, it feels kind of like what Heroku is to Python apps.
Like you can just get push Heroku and it takes your app and figures out how to run it.
Like Netlify is that for purely static sites.
Yeah, exactly right. So I think one of the most surprising things for me was going through the documentation on the website and just seeing how, I guess, fully documented everything was.
It actually tempted me because we use Pelican for PyBytes. That's our static site framework of choice for PyBytes.
So I was familiar with it. But once I got on the documentation and started going through it, I'm like, ooh, I want to try Jekyll.
Because I know Bob's mentioned that. He uses it for his blog. And then I've heard good things about Hugo.
And I just, there's this massive list that you can go through. And so if there's anyone listening to this that has a static site, I totally challenge you to give this a go.
Because it was one of the most satisfying things.
Yeah, it's super cool. And I can't believe what they offer for free, right?
I mean, just to be clear, we have no affiliation with Netlify. They didn't pay anything for this.
Just like, this is really cool. I can't believe that it's actually available.
Like, so custom domain, HTTPS certificates, continuous deployment through GitHub, all of that for free. It's crazy.
Yeah, it's a beautiful tool.
Awesome. Yeah, so if you've got anything static, that's definitely the way to do it. That's cool.
All right, so I guess I'm up next for the next one here.
One of the things I wanted to focus on was just foundational HTML.
Because I want to hear your two opinions on this.
Because to me, I for a long time didn't want to get into web development.
Because I knew I was a good developer, but I didn't feel like I was artistic in the graphical visual sense.
You know, like I was always like bad at art in school or whatever.
So I felt like I'm going to have a hard time designing stuff.
So HTML and CSS and all that like was until I took the time to sit down and properly learn it.
It was actually not a huge roadblock.
But so I'd always try to find like, what is the way I could do this without really writing HTML?
Like what little widget will generate the thing that I want to work?
Like the calendar, because I don't want to write.
You know what I mean?
Like that was me for a long time.
But then once I learned HTML and CSS super well, like it became this thing that I was happy to do.
And I felt like it was made like getting into this stuff much easier and took away all that hesitation.
So I thought it was great.
So I wanted to talk about like the history of HTML.
And there's just some stuff that surprised me there that I thought I would cover here.
So in the GitHub repo on days five to eight in there, there's a section where we go and recreate Yahoo.com and Google.com from scratch as they were in 1996.
That was cool.
It's cool.
But oh my gosh, can you guys believe what those sites used to look like?
Trash.
I don't want to know.
It's so weird.
I look back to 1996 websites and like, wow, it was really easy to actually create a web startup because like Google and Yahoo, we recreated the sites in 15 minutes or something, you know?
And it's just like, wow.
Yeah.
Really?
15 minutes.
Okay.
And now Google is a highly interesting technical foundation, but Yahoo is like a directory listing.
Like you could have finished it up in another hour.
I mean, it was really interesting, but that's all it was.
And so some of the things I found interesting as well is back in 1996, you couldn't use spreadsheets.
Spreadsheets.
Sorry, that's for style sheets.
Style sheets were not introduced until 1999.
Wow.
I didn't know that.
Yeah.
All the HTML attributes had to just be set in the DOM, like over and over.
Yes, exactly.
Right.
Like you would for like a newsletter because they don't know that style sheets.
So that was crazy.
And then the other thing was, if you look at the history of HTML, like there was a lot
of rapid growth from 1990 to 2000.
There was a bunch of versions, you know, every couple of years or something like that.
In 1999 was HTML4.
In 2000 was XHTML, which is an attempt to make all HTML documents formal XML, like a superset
of XML.
So every element had to be closed.
Every attribute had to have a value with quotes for the value and things like that.
Right.
So that was 2000.
The next change to HTML was 14 years later.
So HTML didn't change for 14 years, even though this is like basically on the heels of the
dot-com boom and everything.
Like what happened there, right?
So in 2014, HTML5 came out.
Now I know there's probably like super minor little changes, but like no important changes
happened between 2000 and 2014, literally in the specification.
That's one of the things I actually kind of off topic, but what I love about this is that
you did all this research, discovered all this stuff, and then I got to go and learn
it through you.
So this is all cool stuff because, and I hate to say it, Mike, but you know, back in those
dates you were talking about, I was still pretty, I was still in school.
I'm sorry.
Well, you could have been one of those like kids that started a startup and dropped out
of middle school.
Could have.
No, just kidding.
Should have.
Could have, should have, right?
Yeah.
What are you doing?
I'm going, I'm going to go to college next year.
Yeah.
I'm going to take my yacht on a tour because my business is doing pretty well.
One day.
I'll push that on my kids.
No, I'm kidding.
Yeah.
This portion of Talk Python to me is brought to you by Ting.
Let me tell you about Ting, a new mobile service available in the US that's targeted developers
and other technically savvy folks.
First of all, their average customer only pays $23 a month, but they're no discount provider.
Their service runs over T-Mobile's and Sprint's fast nationwide network.
If you don't use that much data because you're usually on Wi-Fi, like many of you are, then
Ting will save you a ton of cash.
But don't worry.
You can still use as much data as you like for just $10 per gig.
One mobile feature I use all the time is tethering.
And with Ting, you get unlimited tethering at the same data rate with your account.
$6 a month for a phone line, $10 a gig, $3 a month for text if you usually chat over
iMessage or WhatsApp.
Think about it.
No contracts and super clear and fair billing.
Visit python.ting.com.
That's python.ting.com.
And check out their savings calculator.
Enter your usage and see exactly what you'd pay.
Use that link and you'll get a $25 credit to try them as well.
That's python.ting.com.
Or just click the link in the show notes.
All right, Bob, you're up next.
No, you had to commence on HTML, actually.
Well, I was pretty happy that you covered it because HTML is so fundamental for a web developer.
Because when I look at my Django workflow, I mean, part of my time, I'm actually writing
HTML in the template.
So it's very important.
Also, as well as CSS.
It's always something that needs to be styled, even if you're using a framework.
So it's kind of, it's very basic knowledge that web developers should have.
The other thing I'm really astonished by is how far we've come.
The other day, you needed a progress bar.
And now you can have this predefined tag, progress, right?
So no JavaScript, no scripting.
You can just use a progress tag and give it like a numeric value.
And you have your, that's pretty cool.
That is so cool.
Yeah.
We really have come a long ways.
Yeah, but you don't always see JavaScript.
And I do agree that CSS is actually of those skills.
If you can learn the basics of CSS, like that is like kind of a web superpower, right?
That really unlocks a lot of things.
Another part, though, is JavaScript some of the time, right?
Yeah.
No, you cannot escape it.
And you better learn JavaScript.
A good part, actually, because most of the web is powered by JavaScript.
I mean, there's Python, there's the backend always.
But every page out there uses JavaScript and some of them a lot.
So the challenge I had, though, I mean, JavaScript is a whole language.
And I needed to cover it in four days.
So that was tough.
So I really tried to become an essentialist and focus on the essential part.
So the data types and a little bit of ES6, actually, as well, because that's now important to know.
Yeah, that's basically version six of JavaScript.
Right.
ECMAScript six.
Yeah.
Right.
So we have arrow functions and destructuring, map and filter.
So it's likely that you're going to find it.
So I did cover some ES6.
And also within this context, I wanted to talk about React, which is one of the major frameworks in JavaScript.
And again, that was a pretty steep mountain to climb.
So I decided to actually try to make a game, a hangman game, because games are good when you're handling with variables and classes and functions.
And you have to keep state as well as use a user interface.
So I decided to build a game, which was not easy.
But actually, it did give me a way to break a huge topic down into 16 or so segments.
That's cool.
What was your thought of React coming from a Python background?
Like, do you like it?
What's the general programming model feel like?
It was a bit confusing at first.
But then I did start to appreciate it for its design philosophy, especially how it treats mutability.
So I did end up liking it, yes.
But it took a little bit to get into.
There's a lot of moving pieces.
Yeah.
As a web developer, it feels a little weird to me because I always tried to aim for, like, separation of concerns, right?
So you've got your style sheet, you've got your JavaScript, and then you've got your HTML.
And I've always aimed to have, like, the HTML depend as little as possible on the other two and so on, right?
Like, try to keep those focused.
And here, it's like you embed the HTML in the JavaScript little component bits.
It seems a little funky to me.
Yeah, JSX, right?
The new syntax.
Yeah.
That's a little weird at start.
I agree.
Yeah, I guess if the tooling supports it, right?
If the tooling treats that little HTML block as HTML, then it's not so bad.
But it's definitely a mind shift, yeah.
And there are tools to bootstrap your app.
For example, I used Create React app, which I think is from Facebook, who invented the whole framework.
And that did help because you get all your defaults in place.
And you can just npm start and you have a basic structure in place.
So that really helped.
Yeah, that's cool.
Yeah, a lot of these front end frameworks, JavaScript frameworks have like little bootstrappy scaffolding CLIs for them.
That's cool.
So just because I'm a complete noob with JavaScript, right?
And I'm trying to learn it now.
So you're, and this is an interesting point from a teaching standpoint.
You had to squeeze JavaScript into four days, which is just seems unthinkable.
You had to really whittle that down to people who don't know it, right?
Teaching it from scratch.
And so can I learn this myself from zero?
Yes, you can.
Okay.
Now, so this is actually more for me than anyone else.
I mean, it assumes some basic programming knowledge.
I mean, you do need to know what a variable is, but it starts very basic with the data types and basic construct looping and all that.
And, you know, if you already know Python or another language, I mean, a lot of stuff sounds familiar, right?
I mean, a list or array in JavaScript, you can slice as well.
Or, well, you can take an index.
You cannot actually slice it.
Or you can slice it, but it's dot slice.
So it's all very similar, the concepts, but the syntax is sometimes different.
Okay, cool.
Cool, cool.
All right.
Julian, you focused a lot on Flask.
So you cover one of the plugins for Flask called Flask Login, right?
Yeah.
So this one was more like a bucket list item for me.
For ages, I've wanted to deal with how to log in to a website using Flask.
And I got to tell you, Mike, this one, I wanted to rip my hair out by the end of it.
I think it took me a solid month to wrap my head around it.
For anyone who's not familiar with Flask Login, the actual Flask Login part is the easy part.
Everything you need to learn before that is SQLAlchemy to build yourself a database, to build yourself a model for your users to be able to log in.
And I'd never dealt with any of that before.
So this was one of the major learning points for me in this whole challenge, this 100 days.
But it was the most satisfying thing to figure out.
When you look at my page, as you said, Mike, it's HTML from back in 1996.
I think my page looked even worse than that.
But to see a logged out and a logged in sort of view, I think I had a few beers that night to celebrate.
Nice.
Yeah, it was one of the most satisfying things because it's actually really simple once you get your head around it.
There is a whole lot of SQLAlchemy you have to learn or I have to learn.
And I teach this before you get into the Flask Login.
And that was the hardest part for me, as I've just said.
But if you can get through that and if you know that stuff, then the actual Flask Login is pretty easy.
I think one of the greatest parts of it is, you know, as with Flask, there's a lot of stuff with decorators.
And there's this amazing little decorator you can throw on any of your functions for the, you know, the web pages that you're going to be running on your site called, I think it's just Login.
Or is it?
No, no, what is it?
It's Login Required.
Login underscore required.
And you throw that on any of your pages, any of your routes.
And if someone tries to browse that page, it'll check to see if they're logged in or not.
And it was as simple as that.
You sort of had to do nothing else to your site to be able to do that, to get the Login page to work.
That was probably the most satisfying part of using Flask Login.
So that was a really good one.
And if you haven't given it a try, just give yourself a few hours and give it a chop because it actually is quite simple to use.
And once you implement a Logout page to create users so that people can actually register an account,
tie all that in with an SQLAlchemy database back end, and this thing just is beautiful after that.
That's cool.
Yeah, it sounds like a really nice way to do it.
And these plugins for Flask are definitely cool.
It also, if you're using Flask anyway, there's a high probability if you're using SQLAlchemy also, right?
Like Flask is a micro framework and doesn't come with some ORM.
So as long as you're using a relational database, the chances are very high you're using SQLAlchemy.
I mean, you could be using something else like there's PeeWee ORM, which is nice.
You might be using something like Mongo Engine for MongoDB.
But, you know, most likely SQLAlchemy.
So you're already kind of in that space, right?
So here's just the user aspect being handled for you.
Well, the tough part as well is if you're a brand new person to Flask, that getting from that single page Flask app to running a fully fledged Flask app with, you know, your directory structure and views and also having a database.
There's a massive leap there that you have to make.
So get the SQLAlchemy down.
That's the first part.
Then work on your plugins.
Yeah, absolutely.
I feel like I'm not sure what the right way to put it, but I feel like Flask sells itself as being so super simple, right?
Like I create the one file.
I create app.py.
I call the Flask thing to create the app.
I use that to decorate a function.
Hello, world.
App.run.
We're good, right?
But in reality, there's all these other things to it, right?
There's like the database access and the structure and the factoring and the testing.
And there's more to it than initially meets the eye when you create these things.
It's almost like a false sense of security.
Yes.
Yeah, that's why I kind of said I wasn't sure how to put it because it doesn't – I don't necessarily put that forward as a positive, right?
Like Flask sells itself as like, oh, it's just this one file.
But like if you really create an app that's just one file, like a whole website, like you're probably doing it wrong.
You know what I mean?
Like it's so important.
It's kind of like encouraging you to not do the best thing.
So anyway, it's still – it's a great framework.
I like it.
All right.
I guess that puts me next here.
So the next thing I want to talk about is also Flask.
And this one is called Court.
So this puts together a couple of ideas that I find really interesting in Python.
You know, a lot of times you hear people tell you that like asynchronous programming in Python is super complicated.
And it's basically broken.
And like you can't really use it anyway because of the GIL and stuff like this.
And I did a lot of thinking about this and a lot of research on this.
And actually, I think as of Python 3.5 and beyond, like that's not really true.
It's not really – I don't think it was totally true before and it's definitely not true these days.
I think asynchronous programming in Python is really interesting.
So I'll talk about that in a second.
But also things like Flask and Django and Pyramid, none of those support async programming, which is odd.
I mean, it strikes me as odd.
Does it strike you guys as odd?
Yes, a little bit.
Yeah, I'd expect so these days, but it is weird.
Exactly, right?
Like what web apps basically do is they talk to other systems and like coordinate it and then they wait while that happens, right?
Like you make a request.
It talks to the database.
It waits.
Maybe it has another question for the database after it figures out what user it is.
It's going to ask like, well, what's in this category?
They post it over to me and it waits for that.
And maybe it's going to call an API and wait for that.
Maybe it's a cache and it'll call Redis and wait for that.
And it's going to put those answers together in a template and give it back to you, right?
Like it's all about coordinating waiting basically is the way I see the web.
And yet that's the perfect scenario for asynchronous programming.
Like let you do other stuff while you're waiting on the database because you're actually not doing any work.
You're just waiting.
But because of the history of the way these frameworks are built up, they're all based on WSGI.
WSGI is like basically single thread requests.
There's not a great way to do it.
So if you do want to do that, you have to pick one of these many plethora of these brand new frameworks.
Or you could pick this thing called Cort, which is cool.
And I've covered this on Talk Python before.
But Cort is basically a API and plugin level compatible thing with Flask.
But it supports asynchronous methods and async and await and all that kind of stuff.
So that's pretty cool.
So you just basically replace the word Flask with Cort.
If it's a lowercase Flask, it's a lowercase Cort.
If it's an uppercase F on the Flask, it's uppercase Q on the Cort.
And like that's pretty much it.
And things like Flask login and all that stuff still work with it.
And yet it allows you to write async def home or async def login or async, you know, whatever view you want, you can do async stuff.
And within there, you can await your database call.
You can await your Redis key lookup and things like that.
That's nice.
Oh, that is cool.
Yeah.
So it's really nice.
It's interesting if Flask, sorry, if Cort is going to be its own thing in the long term.
I know there was some conversation with David Lord and the maintainer of Cort about maybe like somehow working together if they're so similar.
Like, could we just make Flask async?
And Flask does have async on its roadmap.
I know there's a conversation about Django's async roadmap and things like that.
So, you know, these other main frameworks are working towards that, but they're already existing.
I don't know.
It's a challenge, but there's a bunch of really interesting things there.
And the other thing I want to throw out while we're on this topic that I thought was just one of my favorite things is there's all these different ways to do asynchronous programming in Python.
Like we've got threads, we've got processes, we've got asyncio, which uses the async and await keywords.
But for some reason, threads, you can't use async.
You can't await a thread, which is weird because you should be able to.
Things like that.
But there's this thing called unsync.
And unsync lets you put a decorator on all of your asynchronous methods.
And it will figure out which type of asynchronous programming or execution is appropriate for it.
So sometimes it'll use threads.
Sometimes it'll use asyncio.
Sometimes it'll actually create subprocesses.
But your program model is all the same.
It's just async and await straight across the board.
It's a beautiful library.
I just love that thing.
And I don't think we talk about it in the course here on this stuff, but it's definitely worth checking out if you're doing much with async and await.
It's definitely cool.
So anyway, if you want to play with this conversion from Flask to core for async bits, that's days 21 to 24 in the GitHub repo.
Great.
Yeah, that's a fun one.
Speaking of Django and its async roadmap, Bob?
Speaking of Django, I wanted to ask you, is the async on the roadmap?
Anyway, if it's not, it's still my favorite.
So a big chunk.
Yeah, the Django guys are talking about it.
They're playing it.
It's just not there yet.
I'm sure they are.
Yeah, I'm a big fan.
And so a big chunk of the research and the coverage I had in the course was Django and Django logging registration and Django REST.
So also Django is a very big topic and people find themselves with a steep learning curve.
So the best way to go is to build a very simple CRUD app.
So create, read, update, delete.
And I built a quotes app with one model.
Very simple, but a great opportunity to look into Django's ORM.
So if you're not familiar with these frameworks, one of the things they do is get rid of you writing raw SQL.
So you can use the object relational mapper or ORM and it makes it very easy to talk to a database.
And Django's ORM I really like.
I mean, it's very intuitive and the syntax makes a lot of sense.
Yeah, and Django is different in the sense that like Julian and I were talking about SQLAlchemy, which we both like.
But SQLAlchemy is its own separate thing and you choose to bring it into Flask or Pyramid or something like that.
But with Django, it comes with its own like more integrated data access layer, right?
Right. That's a great addition.
Yeah, because yeah, Flask, you have to set it up separately and usually you go with SQLAlchemy.
But Django has all the stuff in the box.
It's a complete solution.
Also the templating, I think for Flask, you would use Jinja and Django has its own templating engine.
So Django is great if you want to have a complete solution out of the box, but then it is opinionated.
So some people like it, some people don't.
And I do like the decisions they made.
What do you like, Django or Flask?
What do you think?
It's a never-ending battle between you and me.
You're Django, man.
Fine.
Yeah.
So another thing I covered was, I mean, always, usually if you make a website, you need some sort of registration and login.
So I covered the Django registration plugin, which recently was upgraded to 3.0.
Great plugin.
If you need to capture emails and do two-way authentication.
So you need to send an email, confirmation email for a user to confirm and register.
The only thing confusing was that the templates were missing.
So I ended up providing them in a zip file.
Even so, I would really recommend looking into that plugin, which is called Django registration.
And lastly, in this context, I also covered Django REST.
As we mentioned before, same author as API star.
And yeah, it's another great framework that makes it easy, relatively easy to build APIs, but do it on top of your Django models.
So I use the same quote app.
Right.
If you've already got your Django models made for your web app, like if you want to expose that as a RESTful endpoint, like this is a supernatural choice because you only have to put the API, like a thin API layer on top of what you already got.
Right.
Yeah, you basically make a serialization module and that's almost all you have to do.
So it makes it really easy.
And it has also support for permissions.
So I think that's done via some middleware.
And yeah, I also plugged in a swagger for documentation.
And yeah, it was all pretty easy, relatively a few lines of code.
So I really liked Django REST framework and I can highly recommend it.
That's cool.
Do you use Django REST framework in your code challenge platform?
Yeah, good question.
I actually not.
Just use Django, but not Django REST, right?
Yeah.
Django made that pretty easy to do.
We just manually made some API endpoints.
Yeah.
Yeah, I ended up doing that a lot as well.
We were thinking though, at some point we need a mobile app or something and we need to make an API for the whole thing.
Then we definitely want to use it.
Yeah, for sure.
I've been down that road.
Yeah, another module I want to highlight was SendGrid for emails.
Because with the registration plugin, you have to send a verification link.
And SendGrid makes it very easy with their API to send emails.
So I use that as well in this context.
Yeah, the days are a long call and you should set up your own SMTP server and talk to it locally.
Using something like SendGrid makes a lot of sense.
Yeah, and I think I also at some point tried to use Gmail, but then it doesn't really like being used as an API or so.
So it's security concerns.
So it's not, that was not a success.
Lessons you learn.
Why is my email not getting delivered?
This portion of Talk Python to me is brought to you by Linode.
Are you looking for hosting that's fast, simple, and incredibly affordable?
Well, look past that bookstore and check out Linode at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Plans start at just $5 a month for a dedicated server with a gig of RAM.
They have 10 data centers across the globe.
So no matter where you are or where your users are, there's a data center for you.
Whether you want to run a Python web app, host a private Git server, or just a file server,
you'll get native SSDs on all the machines, a newly upgraded 200 gigabit network,
24-7 friendly support, even on holidays, and a seven-day money-back guarantee.
Need a little help with your infrastructure?
They even offer professional services to help you with architecture, migrations, and more.
Do you want a dedicated server for free for the next four months?
Just visit talkpython.fm/Linode.
Julian, what do you got for the next one?
So the next one is actually kind of simple, but again, it was very satisfying, a lot of fun to do.
So I did some Heroku deployment on, what was it, day 65 to 68, something like that.
And it was really satisfying.
So I know with Netlify, I was able to deploy a static site and have it all hosted.
But this time I wanted to get my Flask app.
And one of the best parts was the Flask app that I was creating throughout all of the course.
It's all running local.
You know, it's all local on your desktop.
So this was the chance to get it out on the web, to get it running in a dyno on Heroku and just deployed out there so I could spam it to all my friends and family and say, look what I made.
And they make it really simple.
And this is why I think we use Heroku as well for quite a few things on the side, but they just make it too easy.
And the best part is with your Flask app, they fully support Flask.
So you can just deploy it.
You link the repo that you've created locally to Heroku.
And again, when you push the code up to Heroku, it processes and it actually deploys your site onto your dyno and it's live.
So I think the only thing you really need to throw into your code is a little proc file and a couple of little tags here and there.
And that's it.
Heroku takes care of the rest.
So it's actually really simple.
That was part of what I covered in that section of the course.
But I also wanted to highlight some of the cool features Heroku has.
And again, I'm going to say, I know this sounds like a massive plug for Heroku, but it's not.
I just really like what they do.
They have a lot of plugins that you can use.
I think they call them plugins.
Yeah, whatever.
We're going to call them plugins.
We're going to call them plugins today.
So there are two that I wanted to cover.
Bob just mentioned one, SendGrid, because we use SendGrid a lot.
So again, you can hear that a lot of the stuff we're discussing here, we use actively.
So that's why we wanted to cover it in the course.
But this SendGrid plugin, it links, the add-on, it links with your SendGrid account.
And it's the most minimal amount of code to throw into your code base to then shoot off an email automatically.
And it just works really well.
So I really enjoyed that, teaching that.
In fact, I think the hardest part was making that section take a day, because it was so easy to teach.
It was, you know, I was struggling for things to say.
I probably should have just sang a song or something.
But then the other one I wanted to cover off was Heroku Scheduler, however you want to pronounce that word, scheduler.
But it's just essentially cron, and it makes your life so much easier.
You don't need to go into any backends and worry about it.
It has a nice web interface if you're that way inclined, like me.
And it's just super helpful.
You can automate so many tasks.
You can little parts of your Flask app, whatever you want, with this little scheduler.
Literally put in the code that you want it to run every time.
And it's just, it's really easy.
Really pleasant to use.
Really pleasant experience.
It's not something you get to say very often.
Yeah, that's a great way to describe deployment, right?
Like, normally deployment is something that people got to learn a lot about.
It's really tricky, and stuff goes down.
Like, where are the Nginx logs?
It says it doesn't work, but I don't know why.
I can't figure out where the logs are.
You know, like, so this is really nice.
I know there's a lot of people, like you guys, who love platform-as-a-service stuff, like Heroku.
But there's also a good case to be made if you want a bunch of VMs, depending on, like, how you want to configure things and whatnot, like on the node or something.
So, yeah, definitely, if you're inclined towards the platform-as-a-service side, that sounds like a good option for sure.
Yeah, definitely.
All right, so the next one I want to talk about kind of has to do with, like, deployment and evolving your app over time as well.
And that's database migrations.
So, if you're using SQLAlchemy, Mike Bayer created this thing, who also created SQLAlchemy, created this thing called Alembic.
And if you're using Django ORM, there's migrations built into that as well.
And the idea is that regardless of which one you're using, but I'll talk about SQLAlchemy just to have something concrete.
If your SQLAlchemy class structure does not match what your database structure looks like, your app is coming to an abrupt screeching halt, right?
Oh, yeah.
You're going to get a, you know that, right?
You're going to get a 500 error.
It's going to say operational error database schema, like this column doesn't exist or something terrible like that.
And you'll be like, whoa, that sounds kind of bad.
But, like, if you make a change to your code, like add a column or something, and then you deploy it, boom, your app is taken offline, right?
Like, it will no longer talk to the database.
It's a problem.
So, how do you manage that, right?
Like, some people probably, like, evolve the database manually.
That sounds a little scary to me.
Just because it's, you've got to write the SQL transformations to do it right or, like, open up the tool and edit it.
So, what's great with Alembic is you can just point it at your SQLAlchemy models, point it at your database.
There's a little bit of configuration to set it up.
But then you can just run a command, auto-generate the migration.
And it'll look at your classes and it'll look at the database and go, well, this column was dropped.
This one was added and this index was updated in this way.
And then it just lets you run a command line operation that will automatically transform the database like that.
So, one developer makes a change.
The other developer checks it out.
You know, obviously, that change needs to accompany a migration.
So, then they can just run the migrations as they get the new version of the app.
You push it to Q&A or staging.
You run the migration.
And then as part of your deployment, you can just have it always run a migration.
And, like, if there's no operations, it just goes, you know, if it's up to date, it just goes, eh, nothing happens.
So, we'll just keep going.
So, it's a really nice way to make sure that your database constantly stays in sync with your ORM models.
Oh, that is really cool.
Yeah.
And when I first looked at it, I'm like, whoa, this looks complicated.
Why is this so hard to set up?
Maybe it is.
I don't know.
There's a few little hitches that, like, cause some challenges about, like, how do you import the models correctly from the context of executing within Alembic and stuff like that.
But once you get it all figured out, it's not too bad.
We covered that in day 61 to 64.
So, you can go check out the little sample code there.
Another alternative is to just not use a relational database.
Like, you know, all my stuff, like, in production runs on MongoDB.
And MongoDB doesn't have this problem.
But it also has basically an ORM, something called an ODM for them.
Mongo Engine is what I use.
And it's basically like SQLAlchemy.
It's more like Django ORM, actually, but same idea.
But MongoDB doesn't have this problem in general.
So, you don't have migrations really there.
You can sidestep it that way.
But a lot of people want to use a relational database.
And if you do, migrations.
It's a great way to solve the problem.
Ah, that's really cool.
And I can see it's, so I'm just on the documentation.
And it's actually alembic.sqlalchemy.org.
So, yeah, very cool.
Yeah, yeah, same organization, same people behind it.
Bob, do you guys use migrations, the Django migrations for what you're doing?
Yeah, very simple.
Make migrations.
That makes a file you commit to version control.
And then just migrate.
And then it syncs it to the database.
Works great.
Yeah, sounds real similar to the auto-generate feature there.
It's cool.
All right, Bob, what's your last one?
Slackbots.
That was one of the most fun chapters I worked on.
And, well, we all...
Slack is used for all sorts of things, right?
Like, people chat with it.
But it's also got so many integrations, right?
Like, for example, if, like, I have an error on my website,
I have a Slack channel that Rollbar will detect the error on my website
and then post a message to me on Slack that there was an error on the website, right?
And that's like a Slack bot, sort of.
Sort of, I guess.
But, yeah, there's all sorts of uses for it.
Yeah, when people do a pull request or a code challenge repo,
we get a notification in our pull request channel.
But also, if you think about, like, the general Slack bot, it's super useful.
Like, you can set reminders and stuff.
So, yeah, bots overall are becoming more popular.
So, it's a nice skill to have, I think.
And so, yeah, for this chapter, I looked into Slack API.
And we made a random book slash command.
So, if you type slash book in our Slack, it reaches out to some books API we have for another app we run.
And it posts back some random title.
You can also do slash book and then user.
And you get the last book for the user.
So, that's fun.
That's cool.
And what's nice about these apps is that there's a lot of moving pieces.
So, it's not only the Slack API, but you have to call another API to get your data.
So, in this case, that was Google Books API, which I think has been around forever.
And we had to make a little Flask app for the slash command to actually grab data.
So, it was and retrieving data from an API and making an API.
And then, before rolling it out, you want to test your local server on the internet.
And for that, I used ngrok, right, which is a pretty important tool if you want to, how would I say that?
Link your local host to your internet address or make your local host available on the internet, so to say.
So, you get this kind of temporary IP.
And anybody connecting to that IP is actually talking to your local web server, which is cool, useful.
I'm so glad you covered ngrok here.
You threw this in here because ngrok is incredible.
So, like, if I type ngrok and I give it a port, it'll say I could map, like, port 5000 if I was doing Flask.
Locally, over to, like, 88532ff5.ingrok.io.
And it actually has an HTTP and HTTPS version.
So, at first, I thought, oh, this is kind of interesting.
But I've been using this for some incredible stuff.
So, for example, when I was developing my mobile apps,
I wanted my phone where I had the debugger attached to my phone to be able to talk to the web services that I was building locally with the debugger and PyCharm attached to the web service.
Right?
And, of course, I could drop my firewall and, like, set this up and, like, all.
But we just run an ngrok command.
You don't need to change firewall settings on either end.
It just automatically goes through the internet, through HTTPS, and then right back in there.
And you can step through one, step through the other.
Another one was I was doing some integration with Gumroad for the purchasing of the PyCharm book that Matt Harrison and I wrote.
And we had to do some – there's one option you can buy where you also get a course.
And so, it had to, like, create an account and, like, put you in the course.
And, like, it wasn't working.
So, I put the URL it was supposed to work and it wasn't working.
Like, why is this not working?
And, like, why don't I just put the ngrok URL in there?
And I was literally stepping through in the debugger, Gumroad's callback into, like, my local machine, into PyCharm, into the APIs I was creating.
It is so cool, this ngrok thing.
It's definitely underestimated.
That's really cool.
If you cannot debug something on local host, you're lost, right?
Right.
I mean, here you want to have Slack, in your example, you want to have Slack send a message over and it goes to your HTTP endpoint to do something and then it gets a response.
Like, you can't debug Slack, right?
That's their infrastructure out on the internet.
But you can actually, like, deeply run and iterate on, like, your local version using ngrok.
It's awesome.
Yeah.
Yeah, okay.
I'm excited about that.
I got to stop.
But, yeah, definitely you found it valuable as well, huh?
No, that is cool.
So, the whole ngrok thing is amazing.
I didn't even know you used that, Bob, in that part of the course.
Did you create any other Slack bots other than just the books one?
There's one we actually use quite a bit.
which is called Karma Bot on our Slack.
And if you want to give people credit for contributing to the community, helping each other out, you just use add handle plus plus.
And Karma Bot keeps a local database of users' karmas.
So, the user then gets extra points.
And it's funny how people sometimes react to that gamification.
Definitely boost community participation.
And, yeah, it's all run by a Slack bot.
It's kind of funny.
It's a bot, but people kind of treat it as a human at some point, right?
That's really one of the most satisfying projects.
It's not in the course, but it's on GitHub.
We will link to it.
That's another example of a bit more elaborated Slack API project.
For sure.
Julian, you want to wrap up your section with Chuck Norris?
Oh, yeah, I do.
So, while we're having a bit of fun, this was the most fun I had in the course from an actual fun standpoint.
So, what I wanted to do is, I guess I'll give you the quick background.
It was Flask, but what I wanted to do was give the users a sort of real-life use case.
So, when you make a Flask app, especially when you're learning Flask from the start, one of the easiest things to do is to try and talk to an external API.
So, not make a Flask API, but just go out to an API, pull some data, and then present it on your Flask app webpage.
So, that involves, you know, setting some gets, getting some posts potentially, and then presenting that data.
So, doing something with it to present it on your page.
And it's all little simple bits, but combining it all together is...
I remember when I first learnt this was a bit complex.
So, I wanted to demonstrate that in a few days.
And probably the fun part here was choosing some interesting APIs to play with.
And the first one I chose was the Pokemon API.
Actually, no.
The first one I chose was Chuck Norris.
So, there were two, Pokemon and Chuck Norris.
And the Pokemon one was really nice because what I was getting people to do was enter in a color on the webpage that you create.
And that color then shoots off to the Pokemon API and returns...
You get returned a list of all Pokemon with that color.
And then, you know, the course shows you how to list that data on your page or print it onto your page.
So, really simple stuff, but really actionable.
And you get that instant feedback of, hey, look what I just made.
This is cool.
And because you get to see the Pokemon API, you get to see all the cool little things that you can pull.
So, I've seen people on Twitter who then expanded on this, like spread into another day or two and got all sorts of other information from the API.
And it was just really cool to see.
But what was actually quite hilarious was the Chuck Norris API.
So, I couldn't believe it existed first and foremost, which just killed me for a day.
But the API just returns a Chuck Norris joke.
And the reason this is so funny is because obviously the jokes are hilarious and lame and terrible, whatever.
But I didn't realize they were some could kind of be inappropriate.
And I didn't realize until after I'd recorded everything and put all this time into the course.
And then I got to the end.
I'm like, oh, that joke wasn't fantastic.
So, I think there's a disclaimer in the course now saying, look, just please ignore any jokes.
Just this is more for the API, not so much for the joke.
Yeah, it's funny though.
This was a great chapter to do.
It's really actionable and a lot of fun.
Yeah, and consuming APIs, especially from Python where we have requests and other things like that, AIoHCP client, for example.
It's so accessible.
I think before people try it, if they haven't, it sounds like, oh, this integration might be hard.
Like, usually it's not.
Yeah, it's actually quite simple.
And probably the best part is when you're dealing with that sort of thing generally, or a lot of use cases will have you use forms.
And doing the very simplistic Flask forms that are built in are nice.
And then it's a nice gateway into the WT forms that Flask has as well.
Yeah, it's good.
A lot of good stuff in that one.
Yeah, great.
I want to wrap it up with some JavaScript stuff, actually.
One of the things that I'm not really a super fan of JavaScript, although I use plenty of it here and there.
You know, a lot of people, when they create web apps, they think it has to be like a JavaScript front-end thing, like React or Angular or Vue or something like that.
And then, like, maybe there's some API endpoints.
And I always find apps like that are, I don't know.
They're okay, but they always seem to, like, break down or have these little glitches or just, like, weirdnesses about them.
So I think you can still build amazing apps that are mostly server-side with a little bit of JavaScript here and there as you need it.
But if, for some reason, you do want to build, like, a progressive web app that has an offline capability or something that's a single-page app for whatever reason that doesn't navigate, you know, one of the options that I looked into was Vue.js.
As opposed to, say, Angular, which is, you know, it's got a lot of structure.
It requires TypeScript and things like that.
Bob, you talked about React.
And actually, React is really cool.
There's some great examples.
There's this one of building a whole bunch of different apps, and one of them is this, like, recreation of the Mac calculator.
And it looks really, really good.
I'll link to that as well.
So React has got some cool examples and options.
But I just found Vue.js to be so clean and simple.
You just create a little Vue.js app in JavaScript.
You give it values like name, colon, right, nothing or string or whatever.
And it does two-way data binding.
It's got a lot of plug-ins for editing it.
So if you're building these front-end apps, I definitely recommend people check out Vue.js.
It's just, it's got, like, a real minimal, easy-to-get-started type of front-end framework there.
So another thing that I thought was interesting was Axios.
And, Bob, you and I talked about Axios as well, right?
Like, Vue.js doesn't have a native way to talk to web services.
But Axios, this is a JavaScript plugin library.
I will link to that as well.
It's a super simple way to talk to APIs from your JavaScript.
And it's just, I don't know, I love it.
I'm like, wow, this actually makes this so incredibly easy.
It's a super useful library.
I used it as well in the React chapter to retrieve data from a Python tips API, another API we set up just for the course, another API.
And, yeah, it made it so easy to retrieve data.
It's really, if you're working with JavaScript and APIs, you should check out Axios.
And then I want to throw in two other quick things.
There's something called the Quasar framework, which builds on top of Vue.js.
And it has a whole, just a ton of these, like, widgets and controls that you can just, in Vue.js, just include.
And you get all sorts of great, like, higher-level UI elements that are just pre-built and plugged right into Vue, which is pretty cool.
And then the other thing is something called Vue.py, Vue.py.
And so this is a Python layer, so you can write Python code in the front end of your browser that actually is Vue.js bindings.
Wow, cool.
That's really cool.
Yeah, it's really cool.
So I think it uses Brython.
Let me look real quick, but I'm pretty sure.
Yeah, so you can define, like, a Vue component, for example, by just deriving from the Vue component.
So, like, from Vue, import Vue component, class, hello Vue.py, parenthesis, Vue component.
And it's really quite interesting there.
So I'm not sure that it's a good idea, but it's a very interesting idea.
Maybe it's a good idea.
It depends what you're building, right?
Like, if you're building something that's really sensitive to download, like, I think the Brython element or something is, like, you know, it's not entirely small.
The JavaScript, you've got to download to get that to work.
But, yeah, it's Brython.
So still, like, if it's an offline app or, you know, an intranet app or it's going to be bundled up into something like Electron.js, well, then you don't care about the file size, really.
So Vue.py is pretty interesting.
That was Dias 93 to 96, and people can check that out.
There's an example of consuming a movie service API using Axios and Vue.js.
Well, you guys, that's pretty much it from our course and the topics we're going to cover.
Mostly that's it for time because we've covered a lot, right?
Oh, yeah.
A lot of technology there.
That's, like, six months worth of content.
Yeah, I would say.
And, you know, this is only 12 topics.
So we covered maybe 13 or 14.
A few got kind of doubled up.
In the course, we actually covered 28 different technology topics in these different segments, which is pretty insane.
So let me just ask you about this.
What is, like, after going through all these topics and researching them and studying them, what's your kind of takeaway from this whole exploring the web broadly experience?
Okay, so for me, I would say it's just that there's so much out there.
If you listen to all the noise that you hear on Twitter, if you listen to all the stuff that you find or you read everything that you find and you don't actually just choose something to focus on, you're never going to learn anything.
So my takeaway is, okay, yes, there's all sorts of JavaScript frameworks out there.
Yes, there's all sorts of web frameworks for Python.
Choose one.
Learn what you need to learn to get your job done and then be happy with that because there's always going to be something else that could potentially do it better.
And then once you've got your thing going, then potentially look at something else that might iterate over that.
But, yeah, I just couldn't believe, as I was doing a lot of the research, I couldn't believe how much is out there.
And as you were saying, Mike, how quickly new things pop up because by the time we finished making this course, there was stuff that was around that wasn't there when we started.
And vice versa.
Yeah, stuff that wasn't there when we finished.
Exactly.
There was, what's that library that Kenneth Reitz makes the, not request the other one that he just came up with?
Responder?
Responder.
Like that came out while we were making this course, I'm pretty sure.
So that sort of thing is just going to keep happening.
So this is why I'm flask and Bob's Django.
Bob, what are your thoughts on this?
My takeaway is similar.
There's so much going on that it's easy to get scared and it's daunting.
But I think it comes down to grasping the fundamentals.
So for me, that really is some HTML, CSS and JavaScript.
You absolutely want to know at least the basics of those.
And for Python, yeah, look into a framework.
There are people with more preference for flask, do it yourself or Django, the whole suite in one.
I'm more the latter.
And then I guess go deep in the framework of your choice.
And another, yeah, fundamental.
You always want to know some database skills, even some raw SQL I would recommend.
And yeah, so the fundamentals and then choose the tools of your preference and go deep.
Yeah, that's good advice.
And definitely, Julian, you're right that you can just spend your time constantly chasing
like the next new thing.
And they come and go so fast that like you will never actually get to somewhere to be
like doing something concrete and building it on if you just keep doing that.
Just pick one of these things, start learning, right?
Like you can always transition later for the next project if you decided you like something
better in the end.
But you just got to like put a stake in the ground and start somewhere.
The other one I'd like to point out is you don't have to learn JavaScript to build decent
web applications, right?
Or if you do, it's an extremely small amount.
Like if you listen to people talk on the web, it's like, oh, you got to know like Angular,
you got to know this, you got to know that.
And it's like you can, but you absolutely can build awesome stuff with Django, Flask, Pyramid,
whatever, just using server side stuff and maybe like a smidgen of interactive, you know,
focus this text box or maybe show this dialogue.
But that's about it, right?
You can learn just Python or you can learn just JavaScript, but like you don't have to
like necessarily learn them in parallel.
Yeah, I think that's a great point, especially when people in the community ask like, I want
to make a blog and I need to learn Django.
That's fine, but you can actually use static sites and GitHub, right?
And so you don't actually have to learn Django per se.
So I would definitely really look at what you're building and then try to choose the right
tool because it's easy to overdo it.
All right.
Maybe it's Netlify and Pelican or something.
Yeah.
Yeah, exactly.
Yeah.
Cool.
All right.
Well, that was a lot of fun to talk about those.
Let me ask you both the two questions before we get out of here, though.
If you're going to write some Python code, Bob, what editor do you use?
VS Code?
Vim.
Vim?
It's still Vim.
Yeah.
It's just habits.
Yeah.
Cool.
Julian?
Well, I was going to say Vim because that's just what I use.
But look, if I got to choose some other one, I'd actually stick with Notepad++.
I actually really enjoyed that.
Yeah, that's cool.
And I guess I'll throw mine in there as well.
PyCharm.
That's not a huge surprise to people.
Now, notable PyPI package.
I mean, we explored probably over 100 different PyPI packages for the various parts of this and the dependencies and whatnot of all the stuff that we interacted with.
So, there's got to be some that you're like, I didn't even know about this.
And it's really cool.
Bob, you want to go first?
I guess the question for this episode is notable PyPI packages that's not mentioned before.
So, I cannot go on with Django.
Yeah, it could be one that you mentioned before.
Yeah, but Django would be a bit not a surprise.
Now, for example, for web scraping, right?
Two weeks ago, we had a live code challenge and we were scraping some PyCon Spain website data and beautiful soup, right?
It's a great package that makes it easy to traverse the DOM.
And yeah, I'm still happy with that package.
It's very easy to use and gets the job done.
Yeah, and if you want to keep it short, you could pip install BS4.
Yeah, even shorter.
Exactly.
Julian?
It's actually got nothing to do with web stuff because Flask would be a no-brainer for me here.
But one of the ones that I've used time and time again, especially at work, has actually been PXpect.
You guys heard of that?
I haven't heard of that, no.
It's a little automation library or module.
It's pretty much the main function is to automate interactive processes that provide predictable output.
So, think Telnet, SSH, Git and everything like that.
So, you can automate what's going to happen because you know what your response is going
to be when you SSH to a server.
You know that the password prompt is going to come up.
So, you can code in.
Okay, when you get this exact prompt, now what do you do?
And it's really cool.
There's a whole, obviously, bunch of documentation on it.
But that's a library module I really like.
Yeah, that's really cool.
It does SSH, FTP, Telnet, all sorts of cool stuff.
I love it.
See, this is why I asked this question because I learned something every time.
The one I'm going to throw out there is unsync.
So, I talked about unsync before.
It basically unifies all the different ways of doing asynchronous programming in Python and puts the async and await interface on it.
And it's beautiful because it's only 126 lines in a single Python file.
And yet, it basically fixes most of Python's async API.
It's unbelievable that happens in such a small amount of effort.
So, really love that one.
And if you're doing async programming, check that out.
Yep.
All right, guys.
Thank you for being here.
Julie and Bob.
Thank you.
It's good to be back, Mike.
Thank you for having us again, man.
Yeah, yeah.
Thanks for writing this course with me.
We all learned a lot.
And it was fun to share with everyone a little bit.
Cheers, man.
We'll see you next time.
Cheers.
Yep.
Bye.
This has been another episode of Talk Python to Me.
Our guests on this episode were Bob Bilderbos and Julian Sequira.
And it's been brought to you by Ting and Linode.
Ting is the fast mobile network custom built for technical folks.
Use their savings calculator to see exactly what you'd pay.
Visit python.ting.com to get a $25 credit and get started without a contract.
Linode is your go-to hosting for whatever you're building with Python.
Get four months free at talkpython.fm/Linode.
That's L-I-N-O-D-E.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into
all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our
Everything Bundle.
It's like a subscription that never expires.
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, the Google Play feed at /play, and the
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.