#264: 10 tips every Flask developer should know Transcript

00:00 Are you web developer who uses flask it is become the most popular Python web framework. And even if you've used it for years, I bet we cover at least one thing that will surprise you and make your flask code better. Join me as I speak with Miguel Greenberg about his top 10 list for tips and tricks in the flask world. They're great. This is talk Python to me, Episode 264, recorded may 1 2020.

00:37 Welcome to talk Python to me, a weekly podcast on Python, the language, the libraries, the ecosystem in 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 talk python.fm and follow the show on Twitter via at talk Python. This episode is brought to you by century and linode. Please check out what they're offering during their segments. It really helps support the show. Miguel, welcome back to talk Python to me.

01:03 Thank you, Michael. Glad to be here. Once again,

01:04 it's great to catch up with you. It's been a while we used to catch up a little bit more when you were in Portland, but a little farther away now. So it's nice to see your face in here. How you doing?

01:13 I'm doing good. For those that don't know I'm in Ireland? Probably not forever. I think eventually I will return to Portland. We will go back to pub lunch every once in a while. Perfect

01:25 Berg, I look forward to it whenever that is.

01:28 Yes. But for the time being Yes, I live in Ireland. The plan was to to travel a bit, which of course with the current situation not so much, or actually not at all.

01:40 It's not the best time but you have been there for a while. And you know, I really enjoyed my time in Europe. I'm super happy to be in Portland right now, don't get me wrong. But I really enjoyed living in Germany for a year because it was so cool to just go Hey, it's two hours on the TGV to get over to France and to Paris. Or I could just drive down to Austria or whatever, a different kind of experience over there, isn't it? It's really nice.

02:05 And I'm really looking forward to civilization resuming at some point and and do that for a little bit more time before we return back to the States.

02:17 Well, I'm glad it's going well for you even if you are a little bit restricted in your data, or whatnot, which I'm all behind, right, like we need. We need to do this to get through this. It's such an insane time, huh? Yeah.

02:29 Yeah, I was gonna say that I feel like I've been preparing for the situation, you know, for the last few years. By, you know, working remotely. You know,

02:38 that's really interesting, right? I totally hear what you're saying. And I agree with you, because you and I talked before you move to Ireland, and I think you were thinking, alright, well, we're, I'm moving to, I might not have a job there. So let me figure out how I can like start laying the foundation so that I could work anywhere in the world. And I just happened to be hanging out, you know, outside of Dublin, just, you know,

02:58 enjoying life and seeing things. But you know, maybe still working for somewhere in the States or somewhere else in the Europe, in Europe or even doing your own thing, right. But yes, it's a little bit of everything, actually. And the situation is, luckily so far has not affected my work life. It affected pretty much everything else in many ways. But work. I'm working for Twilio, right now. And that, luckily, is going well, and hasn't been affected at all because I was remote before. So everything keeps going the same way. For me. A lot of the company was not remote, and it is remote now. So there's been big changes for a big part of the company. But not specifically for me and my team, which were you know, we were remote before.

03:43 It's cool. You know, Twilio is a great company. And I'm happy to hear you're working with them. I wonder Do you think that for people like you and me and the thousands of others out there listening who are already on the remote side of things. It's different for me because I don't have like a in office counterpart of my company, right? Everyone I work with that works with me on stuff is all remote. So not so much for me. But I guess for folks like in your shoes where I used to be as well. Do you think this, I guess force remote work experiment that we're all on? Do you think it's made it a little bit easier for you, in the sense that it's like leveled the playing field, right? It used to be like maybe there's a meeting with five people in the room. And then there was like the you and one other remote person or kind of on the side? People would like pointed stuff you couldn't see or whatever. But now everyone has to kind of be on an equal ground. Do you think it makes remote workers? A little bit better off in a sense, I think that will be the case for teams or partially remote, partially in office. That is not my case. Yeah, even though company like your team individually, it's 100% remote. It's 100% remote. Okay.

04:49 Basically what I do at Twilio is I work on editing articles for the blog, the developer blog. My team is you know, editors, I work on the Python side and we have people for different languages. And that's my team,

05:01 right? You probably have to coordinate about like, Hey, we're gonna have an article on this API solving this problem Exactly. in JavaScript, you'll do one in

05:09 Python. And let's figure out what the app is right, we have one meeting a week to basically coordinate and then the rest of the time we work with external contributors. Right, also remotely. So, you know, for for for our team, specifically, nothing has changed. But I would imagine, or actually, I should say, the one thing that changed is that we were getting asked for advice, or all this new people who are forced to work remotely, want to have you know, tips and basically pick our brains.

05:43 Tell us how you do it. Right. Tell us how you make this work. How you

05:46 make this work, right?

05:49 I think it's so interesting to watch the news where they have, you know, like, multiple people on the show are things like The Daily Show or stuff. I'm especially thinking of the news shows with the news anchors, where they all have had to start working from home. And you can see like, week after week, they slowly are figuring it out, right? Yes, they had like super echoey laptop audio for their microphones, they're slowly starting to sound like ironically, like you and I do. And I think that we sound better. I mean, obviously, we do recording and so but also, because we've had to live 100% as with this as our professional interaction. And so to me, like sounding good and looking good. Like we both have HD cameras, we both have good microphones, that is kind of like getting dressed and looking good for business, right? Like when you show up for a meeting and you sound horrible and echoey, people don't want to talk to you, right? That's not a good look, there's a bunch of layers that we're all cultivating here.

06:45 So what I'm very excited to know is what's going to happen at the end of this, I think a lot more people are realizing that it works. You can work from home, and you get all that time, you know, the commute time back. So I suspect a percentage of all the people who are now forced to work remotely will like it will decide that, yeah, I can really do this.

07:12 I think we're not going all the way back to the way it was it's gonna be some of these advantages that people were unwilling to try are going to be seen as advantages are going to stick for sure. Mm hmm. Yeah, yeah. Yes. How about we talk about some flask, something definitely talked about for for many, many years. So we were talking before and you were on episode 48. over four years ago, we talked about building apps with flask. And then you were on episode 121, where we're talking about microservices, and really with a bit of a flask angle there as well. So you've been a fan of flask for a long time.

07:49 Yeah, I was a user of flask first, and probably told this story in the first episode. But you know, quickly, I wrote my blog with flask, and then not knowing what to blog about. I decided to blog about flask at a time where, you know, I wouldn't say that it was an obscure framework, but, you know, certainly didn't have the following that has now. So my articles, for some reason, were the first that you know, outside of the frameworks on documentation, and it started growing at the same time, I decided to blog about it.

08:24 Yeah, you just catch the wave at just the right time and pick, sadly, but at the same time, you know, you saw the framework, you're like, No, I'm not going to do it in Django, or whatever else, I'm going to do it in flask. Right. So there's some, you know, picking the right

08:37 ideas. And part of my I'd like to think that this was a little bit of my doing, I showed why, in many cases, flask was the better choice by writing tutorials, usually my blog, and showing actual examples where you could do things that, you know, usually I'll consider hard, and they're not so hard when you look at them through flask.

08:59 Yeah. To me, flask, I'll compare it to Django, because that's its biggest alternative. Right? There's certainly all these other new thing. There's there's so many new web frameworks coming. I don't know, I'd like to hear your thoughts on this actually is Oh, yes. There's there's so many new cool little frameworks. You know, we got FastAPI, we have API star, we have scenic just all these. They're not all necessarily leveraging the new asyncio stuff. But a lot of them seem to be like, hey, these other frameworks didn't really solve my problem, because they didn't support async. So we're going to create something that maybe leverages type ns plus async. That's kind of like flask. But when you think about some of those, like, where do you see the action there?

09:44 First of all, I'm very excited that the model for all these frameworks is flask, right? They all Yes, do kinda like flask, as you said,

09:53 yeah, that is what was really surprising to me. So if you compare flask against Django or against pyramid or against the other frameworks, And you look at their popularity, like I think flask is we're talking neck and neck. But I think actually, if you look at the newer projects that haven't been around for a while, flask is pretty clearly ahead of Django in terms of popularity, like Django apps that people are still working on today. Yes. Do you work on Django or flask? It's, a lot of times, I think it means I work on a Django app that's been around a while, not that there's anything wrong with Django, but just in terms of that growth. But then if you look at flask as the, like, the idea of it, that all these other frameworks seem to think that this flask style, yes, slight adaptation is what they want, right?

10:38 Yes, big reason for that, I think is the we are moving a lot of the logic, the business logic and applications to the client side, right with all these new JavaScript based frameworks for the browser. So for sure, what's left to do in the server is really, the database is storage Related Actions, and maybe authentication, surely application. And that's it. So we look at a framework like Django, you can do that really well. But it has a lot more components that you really have no use for. And, you know, all these new frameworks model after it. sort of give you just the API portion of your server side part of your project. Right. It's

11:23 kind of just enough server side. Yes,

11:25 right. Now, I will say that it has a little less, and then you can pick, you know, the right extensions to make it exactly what you want.

11:31 Yeah, right. Right. add on. Yeah. That's a good point. I'm still a fan of having a decent amount done on the server side. I don't know I just, I like the instant. You know, I do. It drives me crazy to see these pages sort of like build up as I interact with them, you know, you'll see like, oh, you're logged out, no, wait half a second later. I'm logged in, like, you know, just that kind of stuff. I'm not a huge fan,

11:55 you should find the right mix between, you know, server and client. I think people are too quick to go to build everything as a single page app, React view, agree Angular, you know, those types. And they don't think about doing a right balance. Sometimes you don't expect everything to be done in a single page. It feels weird that the whole page is changing. But it's really done in react, for example, which is slow and weird. It messes with the Back button in the browser, I prefer to basically use the single page app, only when you see a clear benefit, you

12:33 really need like an interactive thing. I'm building like a little dashboard I'm exploring or something like Gmail or something like it's perfect, right? But it just be the one hammer, you hit everything within the web,

12:44 my blog, the blog that I wrote, six, seven years ago, when I started with flask, it's still a traditional application server centric, and that's just fine. It has a little bit of JavaScript sprinkled here and there to make it a little bit nicer. But you know, it's mostly server side. And I think for a blog that works really well. Yeah, I agree. So you're talking about the front end frameworks, like I agree, like don't overuse them, whatnot. But sometimes they make a lot of sense. What ones do you like, right? Now my preference, and this is going to generate generate a little bit of disappointment in your audience, I think, is vanilla JavaScript, that is the framework or the no framework that fits my brain the best. So I can do whatever we want in vanilla JavaScript. A few years ago, I would say jQuery. These days, you don't really need that the jQuery was a layer that will make all the browsers sort of uniform. And these days, the browser, the browser's are pretty good at being uniform with each other. So that's my favorite. Out of the real frameworks, React is the one that I've used the most. But only for simple apps, what I've seen is that all these dependencies that are generated between all the other parts of a page, it's very easy to get them completely out of control. As the project grows, right, at least I personally find having a handle like, for example, when writing vanilla JavaScript, having a handle of what part of the page, it's related to what other part makes it for a much faster and dynamic application. For small examples. I think react is a good model. And that is what I use nice.

14:27 If I did throw my vote in for one, I put it on view. I like jazz a lot. I like just quickly just bring it in and include a JavaScript file. You know, pull out an ID and say what this little sub part of the page is now an app. I really like that. Yeah,

14:41 we will be my second choice, actually. Yeah.

14:46 This portion of talk Python to me is brought to you by century. How would you like to remove a little stress from your life? Do you worry that users may be having difficulties or are encountering errors with your app right now? Would you even know it until they send that support email How much better would it be to have the error details immediately sent to you, including the call stack and values of local variables, as well as the active user stored in the report. With century This is not only possible, it's simple and free. In fact, we use century on all the talk Python web properties, we've actually fixed a bug triggered by our user and had the upgrade ready to roll out as we got the support email, that was a great email to write back, we saw your error and have already rolled out the fix. Imagine their surprise, surprise and delight your users today, create your free account at talk Python dot f m slash century and track up to 5000 errors a month across multiple projects for free. flask is on the rise. I think it's on the rise in its own right. And I think it's on the rise in the sense of its API, as we talked about. So let's dive into the 10 tips that we're going to talk about, yes.

15:55 10 tips. Yeah, what do you got for number one? Okay, number one, it's actually very specific to API's, okay, you do not need to use the JSON phi function anymore. So this is in a recent flask releases. For many years, if you needed to return a JSON response, you had to call the JSON API function, which would take a dictionary or list and convert it into the actual JSON payload that goes out to client, right.

16:23 So if I've got a view method, and I wanted to return JSON, I can't just say return a dictionary or return a list and have it internally serialized to JSON. Right? Right. Oh, like,

16:35 not work? Not until now. So I've always done JSON fi as well. Now, what can I do instead? So basically, now you return a dictionary. And flask will itself say okay, this, this goes out as JSON. So it will JSON if I the response, set the correct content type, and all of that. So

16:54 when I think about this, what else has to be done to make this work? Do I need to add anything like to the route decorator to say the response is JSON, not worth it enough? If the client don't check in says, except type is application slash JSON? Or what do I need to do,

17:09 you don't need to do anything. So this is always flask looked at the type of your response that you return in your view function, there were always different behaviors depending on the type. So if it was a string, it would send it as a text, if it was a response object, it will send it us basically whatever you saw object, and so on. And now there's one more type if you return a dictionary, then flat says, Okay, this is JSON, it basically sets everything up for the response to be all done for you. So free, great, I'm not importing JSON fi anymore. There's no need at all to import that function, and then have it in every single last line of all your view functions.

17:55 Yeah, that's really clean. I definitely like that. That's something I've really liked about the pyramid web framework is you've been able to do that the whole time. You just return some data type. And it'll serialize it. Yeah. So really glad to see this is nice and clean. And I think when I first started doing flask, I was like, I'm gonna try to return a dictionary. Oh, it doesn't like that. Now, I have to go hunt down. So I ran across JSON fi and I didn't realize that that had been sort of more Yeah. made more general. So you don't have to be that's great. Yeah, it's

18:21 really nice work for many years. I used to decorator specifically for that. It was an art. Yeah, Jason, that I even taught in many classes, how to create a decorator that that will take that response dictionary.

18:33 Absolutely. And I have I've created a decorator exactly like that. That takes in the decorator, you specify the Jinja template, and you return a dictionary, and then it'll like send that, you know, render template with that dictionary as well. I'd love to see those kinds of things built more into flask. I mean, I know this one's no longer relevant. But there's a couple of things like that. That would be kind of cool, I think. Yeah, very nice. Okay, so no more JSON API in our API's a little bit less code, right? It just makes it cleaner. I love it.

18:59 All right. Number two. Number two is do not store sensitive information in your user session. I see this a lot. It's so convenient. You have you know, from flask input session, and then session works like a dictionary. And it's so tempting to write any kind of information there that, you know, in the next request from the same client, we can recover. It's preserved, right per client,

19:24 right. So like, if you log in, you could put like the user ID in there. So then the next request, you could write back,

19:30 so you suddenly put the user ID. So it's very important to remember that unless you configure flask in a non default way, those sessions are not encrypted. And they are sent in cookies to clients. So the client is storing all that information that you put in the session dictionary. So you should definitely never store information that you do not want to be public,

19:57 right? At least the user could go in there and see it or they could go in and they could mess with it. Right? They could tamper with the cookies and whatnot. Right? You definitely don't want that.

20:08 So that's actually a good point. They could not clients cannot modify it. The cookie is a secure cookie. Okay has the content. It's not clear text, but it's also not encrypted. It's in base 64 encoding, which is very simple to

20:21 vit is like visually encrypted, but that's all it's visually encrypted. Right.

20:25 So it's base 64, encoded, but there's also a crypto signature in the cookie I see. Okay,

20:31 so it's tamper proof.

20:32 But if you make any changes in the client, and then try to send that cookie again to the server, flask will say no, this is not the signature is incorrect, and it'll throw it away so so that that's not a problem. So so it's safe against tampering, but it's really not safe against seeing what the information is. So never store cookies or sorry, secrets, passwords, nothing of that sort. Yeah.

20:57 So I've never used the session feature of flask. I've always just said, I want to store a cookie. And it just has like one piece of identifying information to like carry on that session. And then I'll go back to the database to get the rest everything else right. Okay, should I not be using this? Like, should I be using session, should I look more into it

21:17 session, it's actually very convenient. And flask has a plug in architecture, you can install different types of sessions. The default is that the cookie or secure cookie based session that that I just described. But there's an extension called flask session, which provides sessions that are stored server side. So this, this extension provides a number of storage mechanisms, you can store them in files, pretty much in the style of PHP, if you've seen how those are stored in sort of, I mean, in a database, right? Well, SQL, okay, another example a Redis. Yeah, there's a Redis back end as well. So flask session will be you will have to do that if if you want to store sensitive information in your session, and then you will be safe, right? Because the only thing that will go on the session cookie in that setup will be the session ID. But all the information will be safely stored in the server. Okay.

22:09 Yeah, that sounds like a pretty good thing. In the server side bit is nice, right? So you can store those things, but not actually setting them. And even if it's not, because it's sensitive, maybe it's not reasonably serializable. Or it's not, maybe it's just a lot of data, right? You don't want to send, like cookies are limited and how big they can be. And you don't want to exchange like huge cookies anyway, they need to be

22:32 there they are encoded to JSON before. The base 64 encoding supplied. So the whatever you're storing the session needs to be JSON compatible. So string, a number, a list of or a dictionary. So yes, definitely, there are some limitations.

22:48 All right, what's number three? kind of related? Oh, before we move on this one, though, I wanted to say one thing really quick, maybe a 2.5 2.7, something like that. You're talking about exchanging these cookies. And I was kind of thinking Well, okay, so the user really needs to be careful about like, it'll be on their filesystem somewhere as a stored cookie, they can go to their dev tools and look at their cookies and whatnot. But it's kind of safe to the world. That's making a really big assumption that that connection is encrypted.

23:17 Right? Yes. And actually, these 10 maybe we should have an 11th tip, which is always use HTTPS.

23:24 Yeah. Yeah, that was gonna be my 2.5 is like Let's Encrypt,

23:28 right? Yeah, you always have to have encrypted servers when you deploy for production. Even if you think that you have nothing that's sensitive. In this day and age, there's really no reason to risk it. Because you can get a free SSL certificate from Let's Encrypt, it's incredibly easy to set it up for Let's Encrypt. It's very easy to set it up.

23:49 Yeah, I had resisted it, because I was like, I don't really want to learn how I already have this other SSL certificate I bought, it's like good for three years, but I don't want and then I finally just said, All right, I'm gonna find out like, I'll just get Let's Encrypt working. Just think about renewing this other one. And it was like, 10 minutes later, I'm like, Oh, that was really easy. Yeah, that wasn't

24:06 learning it. You know, the second time it's even quicker. Yes. And the certificates last, you know that they're short lived the last three months. But you said set it up so that they automatically renew. And it's something that you never need to think about the basically they just work. Yeah, so yes, absolutely. You always have to have SSL encryption on your sites deployed to production.

24:26 Yeah, two more aspects of that, obviously, the we think of privacy when big encryption. But SEO, Google is taking into account whether a page is secure or not, as well, these days. And they also take into account performance. One of the really nice ways to get performance these days is to just do HTTP two. Right, and I'm pretty sure that only runs over SSL,

24:50 I'm not so sure about that. Maybe, you know,

24:52 okay, I can't, I feel like I tried to set it up before. I don't know. I think I'll mess around while we're talking and figure it out. We should definitely

24:58 figure it out. And In general, I've found that you can add all the HTTP two solutions, you know, outside of your web application, I don't find that I need to worry too much about that within flask, for example, you put a reverse proxy in front that will take care of that. That's actually the same idea that I'll apply to the encryption in general, I prefer to leave that to tools that, you know, that do that well, with a native language, not in Python. It's way faster and more efficient. So although things are good to have, but luckily, they haven't changed, at least for me how I write my web applications in Python flask. Yeah,

25:39 same. I'm doing HTTP two for myself. And it's like, most of that is around serving the CSS and the images and the JavaScript through nginx. And like, that's even before you talk Python, right. Okay, so let me read something really quick. And you interpret it for me, this is from ssl.com says, browsers distinguish between clear text HTTP two and HTTP two over encrypted TLS as two different protocols. As of this writing, none of the major browsers support h two C, which is a clear text version, which means TLS encryption is mandatory. So the protocol specifies a non encrypted version, but apparently the browser's

26:15 none other browsers.

26:16 Right, at least as of 2000, November 2018. Right. So maybe they have, but I surprised if they be I don't see why they would. Right, exactly. So I think theoretically, you don't need SSL, but in practice, you need SSL. So one more reason. I guess they're cool. All right. more secrets. Number three,

26:35 okay, another secret related one, you should use a dot e Nv dot m file to store your secrets. I'm sure if I go search GitHub for the standard names that people are assigned to AWS secrets, or even Twilio, passwords, and all the things, all these things, I'm sure I can collect a bunch of them, right that people put in source code, and then they forget, yeah.

27:01 And that's fine until it's not, it's fine. Because your God, we're not going to open source this and then somebody does, and they don't realize it. And then yeah, bad stuff happens, s3 buckets are exposed, and

27:11 so on, right? So you should get used to never write a password or a secret or an API key directly in the code, even if you're doing it for a quick test, because it happened to me many times, I think that I'm going to do a quick test. But then that evolves. And eventually, I said, Oh, this is a cool thing to show you in jest. And then offer goes to GitHub. So never do it. And then you'll be safe. What you need to do instead is to replace in a place where you are going to write the password or secret, just read an environment variable, and then get used to always have the secrets that you're using your applications in environment variables, right?

27:51 That's helpful for things like

27:53 Docker as well, it helps you like your create these more isolated, reproduce elements. So that totally makes sense. I've heard put them in environment variables. But what's the story with the dot E and V file? How's that relate? The problem is that people find it annoying to have to set environment variables, because we set an environment variable, the life of that environment variable is the session, right? If you close your terminal window, let's say we're talking about development, right? So right, at the end of the day, you don't have your machine the next day, all those environment variables are gone. Right. So my recommendation, and something that works really well with flask is that you put all your environment variables in the dot m file, and then flask in recent releases. If the package Python dot m is installed, we'll just import all those variables. When you run the application, it basically sets them as if into the

28:47 environment. If you ask for them from the environment dictionary, they'll be there.

28:52 They'll be there in the same way as if you have set them by hand on your terminal before running flask run.

28:58 Okay, what's the name of this package? Python dash dot m,

29:01 dl d? Yeah.

29:03 Cool. I'll put it in the show notes.

29:05 So even if you don't use flask, this package makes it so simple to import a dot env file each need to call a function load buttons. That's it. And then after you call that all the variables that you stored in the dot m file will be in your environment.

29:21 So I totally agree with this. But I always wonder what people use to persist and version and keep those types of things. Where do you store the stuff? So if you got a new computer, or you got a new team member, how do you get them that information, I'm going to

29:37 tell you what I do. Some people may like it, some I'm guessing want, but what I do is I create a dot m template, usually call it dot E and v dash template or something very clearly that you can see that it is an example of how your dot and file should be structured. And in that template file, I write the variables the equal sign, and then I leave it empty. So while you're installing your application in a new machine, you copy the Dorian v dash template to Dorian v. And then you fill out your secrets. And yes, it is annoying, but it's only the first time when you're installing in replication. That's the only time you have to do it. And then it works. Second to that, you have to put the dot DMV file in your Git ignore file, because you of course, don't want to commit that on purpose or by mistake to source control.

30:31 Right, that kind of defeats the purpose. Right? Of course. I think that might be a default in GitHub, if you pick the Python ignore template. Can't remember, but I think so. No, actually, I wouldn't say that. That was my complaint. I don't believe it is. Oh, it's just vnv not dot EMP.

30:46 Right? I don't think they have dot EMP, even though you know, it's actually fairly standard, many technologies and many languages and frameworks use it, but I don't believe it is. I'd like to see it there by default.

30:58 Yeah. Well, you know, that these Git ignore templates are like projects on GitHub, right. So like github.com slash GitHub slash Git ignore is the project where those are kept, we could do a PR, see what they think we should do a PR,

31:13 definitely we should do

31:14 a PR Yeah. This portion of talk Python to me is brought to you by linode. Whether you're working on a personal project or managing your enterprises infrastructure, linode has the pricing support and scale that you need to take your project to the next level, with 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise grade hardware, s3 compatible storage, and the next generation network linode delivers the performance that you expect at a price that you don't get started on the node today with a $20 credit and you get access to native SSD storage of 40 gigabit network industry leading processors, their revamped Cloud Manager cloud.linode.com root access to your server along with their newest API and a Python COI just visit talkpython.fm/ linode. When creating a new linode account, you'll automatically get $20 credit for your next project. Oh, and one last thing they're hiring go to lynda.com slash careers to find out more, let them know that we sent you. Good advice. Another thing that I've seen, this is not the same. It's the same vein but it's not the same thing is and this honestly sounds better. But also pretty good is usually we're using virtual environments for web apps in any meaningful app, right? So the virtual environment you create has an activate script, you can set environment variables, there. So anytime you activate the virtual environment, it's always got its environment variable set. It's kind of the same. You couldn't know when you got to reset them. But somewhere, yes, it's a little bit more difficult to remember to do it when you do a new installation. Yeah, but but it's definitely a good README, pointing you to do. It should help and yeah, give the same result. I think the one difference is like the dot EMP template, explicitly kind of reminds you that there's some kind of thing I've got to do, where's the virtual environment is like magic. Like it's good when it's set, and it's working. But there's no indicator that this

33:10 is a step you need to do? Yes, there is a good point, because when you call the load dot m function from from this Python dot m package, if there's no dot E and V file in the file system, it'll print a warning. So you will see a warning in the console.

33:24 Nice. That's good and perfect. All right, what's number four?

33:27 So this is not specific to flask. But for many years, people who use Windows, they're sort of treated like second class citizens, right? Because most tutorials I've written for bash and you know,

33:40 yeah, Unix diced das

33:42 ways V and V been activated. Like, wait a minute, that doesn't. That doesn't work. The bin doesn't work. What about right,

33:48 and then the forward slashes versus the backward slashes that you use on Windows. So in recent years, there's also Chromebooks, which are another group of people who are users of Chromebooks, who sort of felt at a disadvantage, because you have a perfectly fine machine where you should be able to write, develop code write Python, but for many years, it was not possible or required hacks on the device itself. So these days, both Windows and Chromebooks both have Linux emulation solutions. They're not the same, but the end result is that you get a Linux prompt, will you get bash or C shell or your favorite shell that you like? And then basically, you could run Ubuntu Linux in your windows or Chromebook machine? Yeah. Nice. So I don't use Windows so much now but I have a Chromebook. I can do pretty much anything I do on my Mac laptop on the officially supported Linux emulation on the Chromebook. So definitely take a look at the W SL the windows subsystem for Linux if you're on Windows, or the Linux files support if you're on Chrome OS, because on both You can even run the Ubuntu or other distributions, that's the default. But you can use a different one if you like. And you can run Python, you know, recent recent versions of Python flask. And all of that works exactly like it would on a Unix or POSIX type OS. So you will be able to follow tutorials using the standard instructions that you see for Unix. Yeah, that's cool. And the windows subsystem for Linux two was just released not long ago, which is a big improvement, I understand. It's actually an improvement in performance. And it's actually more directly. It's less of a VM, virtual machine solution. It's kind of more linked

35:40 between the difference to gym environments and apps and whatnot. Yeah, like you can open explorer from your Linux and to get your filesystem, stuff like that. But I think actually, the Chromebook story is bigger, because one of the important places people might want to use both Chromebooks are, rephrase that they have a Chromebook is their only option. And they want to learn Python or programming is in the educational space. Oh, yes. So many kids have Chromebooks. My daughter has a Chromebook from her school. And if they wanted to do Python, they could maybe do some online thing, maybe war where the answer was no, you don't do Python, right? It's actually hard to even

36:15 an SSH connection to a remote server. You can but it's tricky. It's not immediately obvious how to do it. But now you can run your own local Ubuntu distribution in the Chromebook. Nice, cool. That's a big deal. And it's all official, it doesn't require any hacks. It's all sanctioned by Google and developed by Google as well.

36:36 Cool. And shout out to the folks over at canonical for releasing Ubuntu 2004. lts, the first release, yeah, in two years. So it's super awesome. And it comes with Python three, eight, as the default in Python two is not even installed. So the Python story is better there. And obviously, just the new Ubuntu is nice. But Alright, number five,

36:57 number five. So this is a thorny one. A lot of people to this day don't understand the contexts in flask. Most people don't see this, but they only learn about it when they get an error. And there's actually two different errors. And they're so similar that people think there's only one and the two errors are you're working outside of the application context. That's number one. And then the second one is you're working outside of the request context. And

37:24 I suspect this is where people are going just statically saying flask dot request dot property. But that's not set right there. Because they're outside the context. Yeah,

37:33 this comes all from the philosophy of flask, which is to make all these variables, let's call them variables that are global in nature, to be magically available. So you import, for example, current app, or your input request. And then you just use it as if it was a global variable. It's actually there's a little bit of magic underneath these imports, but you use them as global variables. And if you use them in the wrong place, then you get the right so once the context is created, these are what thread local storage, basically, yes, they think limitations based on thread local storage. So they basically belong to a thread, right?

38:12 That's the request coming in through like micro whiskey or something like that. sets that and then the rest your app just has it correct.

38:17 So okay, the interesting thing is that people don't realize that these are very different. If you get the you're working outside of the application context, error. That means that some piece of code wants to know what the application is. And all you need to do is set the application context yourself. If you look in the flask official documentation, it shows how to do it. It's a single line. There's even a context manager to do this. So you set the context and then your code will work. And you solve the problem. That's it. Yeah, the issue is when you get the other one, and people confuse the two. But if you get you're working outside of the request context, that typically means that you have a bug in your application, you're trying to get information about a request. And there's no request, which means that you're running this code, right? Maybe you kicked off a thread

39:09 or something weird thing like that, yeah,

39:11 you're doing it in a place where there's no information about the client. So you know nothing about a client or a request, I see that indicates that you have a blog. And people find racy ways to fix that, basically, to avoid the error. And a one that I see a lot is that flask has this way to create a test request for unit test. Right? If you create a test request, then you can invoke request dot something and it will work. But the information that you get is so fake. So yeah, I mean, the fact remains, you're probably doing something in a place where you shouldn't be doing it. So application context. If you get the error, you set the context and you're good to go. It's perfectly fine. Request context. You need to look at your code, you probably have a bug, you're doing it wrong. Are you doing it wrong?

40:01 All right, what's number six?

40:02 Number six is still related to this topic. I've seen many, many applications that have, for example, have celery workers or any other type of ciliary processes, maybe cron jobs, and all those things. So let's say you have a web application written to flask, and you you're using flask SQLAlchemy, for your database. So when you go write the celery side, or the cron job, what do you do you create all the models using flask, SQLAlchemy, and that Extension has a very nice way of managing your connection, you don't have to worry about it actually, right. Create

40:44 the engine, create the connection, create the table. Yeah,

40:47 right. All of that is done. You don't do any of that, right? When people start coding their celery workers or cron jobs, they say, Well, okay, I'm gonna have to do all of this myself. They create their SQLAlchemy engine and, and they have to figure out crazy ways to get the models which have written to inherit from DB dot model, which is a flask SQLAlchemy class, in to inherit from the base is declarative base from SQLAlchemy, and invent a lot of crazy ways to make that work. And the fact is that you don't have to, you can create a flask instance, and instantiate flask, SQLAlchemy, and then not start a server. And you can use the database just fine,

41:29 right? If you just don't call flask that run your kind of everything set up anyway,

41:32 don't run the server, but create a flask instance, in the celery worker in the cron job, it doesn't matter. Scrape coded the Create app function to make it an application, configure it exactly like you configure it for, for the server, but then don't start the server. And then that gives you access to using all the extensions, you can use the database through flask SQLAlchemy just fine. There's absolutely no problem. Another big one is sending emails. So if you use the flask mail extension, it's exactly the same thing. You can send an email from a celery worker, you don't have to look for a different library, you can just create a flask application instance configure it, and then flask mail will work just fine.

42:13 Yeah, well, it's sending email is exactly why you would do this on another thread or no background. Because if you're sending one email, fine, it's probably okay. It's not ideal, but it's fine. But I ran into this thing where I had thousands of people sign up to get notified when I posted a new office hour, because I have free office hours for my people take my courses, they can drop in on zoom and chat and whatnot. That started to grow, I remember hitting it and it like literally timed out the request, trying to send the emails, and then it was halfway through sending the emails or some percent through. But I didn't know how far so I didn't know how to go back and send the rest of the email. So I'm like, well, the other rest of the people are just not getting sent, because I'm going to email the first half again, right? It's just like, it's not a thing you do

43:00 as part of requests is really sad that similar stories happen to me. And yes, that's actually a good reason to send the emails to a background job. And then it can take as long as it needs. But yes, you you will need to create the flask application instance, you will need to set the application context, because in my particular case of both flask, SQLAlchemy, and flask mail, they need an application context, because they need to get the configuration that's all they need. That's actually they don't really care about flask itself. But they have the configuration variables in app config. So you need to set the application context. So they need the first part, they need the

43:44 app part. Yeah,

43:44 right. They need to know where the app is. So only so that they can get to the configuration. And then they can know what the database is what the email server is. So definitely do it that way. And then you can have a consistent way of working with database or emails between the server and your auxiliary processes.

44:01 Yeah, that's great, great advice. I now when I'm doing something like email, even if I'm just sending one, it's on a background job. It's not part of the request.

44:08 It should always be and people don't realize this, but sending an email is actually very slow. It takes a few seconds, if you're lucky,

44:15 right? Well, it also depends on things you don't control, right? Like you probably control your database somewhat. But if this is like some external mail server that's then talking to some other thing. It's

44:24 Yes. And you know, many, many servers introduce artificial delays. For security purposes. There's a lot of tricks that many servers implement. The story is that sending an email takes two three seconds, at least just one at least. So you should never be done in the server, you know, in the foreground of a server route, right? Absolutely.

44:44 All right. Number seven, this is what I kind of nudged you to cover. Yeah, this is this is a good as I'm a fan of it. But yeah, tell us about this one. I'll jump in as well. But if you want

44:52 you surely know this one better than me because I found out a few days ago when you pointed this out, but secure.com is a project that provides a lot of security settings around how you configure your cookies, your HTTP headers in your requests, especially your responses, not only for flask, but for a lot of frameworks, a really long list of frameworks. Now, this is one of the things I really like about this project is because

45:22 if I go learn how to do secure headers in pyramid, then I go write a flat my flask API, I've got to like, rethink, okay, well, what does this default to? And then how do I do it? And what's cool about this is it's like literally one line when piece of middleware or callback, and you've got all these things added. And it works for flask pyramid, Django, like starlet and the newer frameworks, right?

45:45 The async. io frameworks,

45:48 right all the core, which we'll talk about responder, like it has support for all so you just do the one thing for that framework, the one line and then you're good to tell us about like why do we care about these things? What does this

45:59 do is a number of things that the default configuration for for flask and for all the other frameworks, they don't do. And the reason why many of these things are not set by default is that they don't make sense during development. And that's one of the reasons

46:14 Yeah, yeah. Like strict transport security, for example, like right here on SSL to just run localhost, right? You

46:21 work that will be an unnecessary complication, or setting the the secure bit on your session cookie. That's the other thing that you will not do when you are working in your application. But you definitely need to do when you deploy the application for production, right?

46:37 If I have that, right, that means I'm only allowing the server in the browser to exchange that cookie, if it's an SSL

46:44 request. So maybe I type the domain name, but I don't put HTTPS at the beginning, in HTTP, and then HTTP redirect to the US, it's a very clever hack that some people exploit, the browser will send your cookies and list all otherwise, regardless of you are going to the site via HTTP or HTTPS, the browser doesn't care, unless you tell the browser that the cookie should only be sent on the secure connection. So the default is not set. So cookies in flask are not secure. What people do is they call your site with HTTP. And that basically forces a cookie to go from the client to the server on an unencrypted connection. Right? It could be intercepted, right? And then probably your server will say, Well, I don't have HTTP, it'll do a redirect to the same URL if you

47:36 like. Yes, it's true. Like the cookies been exchanged. Yeah, time.

47:39 That's too late. Exactly. The cookies been, you know, traveling the network, you know, unencrypted. Yeah, definitely. This is a good way if you don't want to think about security. And, you know, ideally, most people, they're not security experts. So this is a good way to make sure that you have the baseline of your of your security protections all in place. Yeah.

48:00 So some other things that it does is it prevents your site from being embedded in an iframe and another site automatically, right. So people can't spoof yours, like wrap it with something else. That turns out the strict transport security, things like that. Yeah,

48:15 the list of things that they do, it's actually way more than what I would have done myself, or what I do. myself by hand,

48:22 it's definitely worth it comes from the Oh, wasp, like, which is a web security group. It comes from the recommendations, and it just automatically adds it. And I imagine if there's a new recommendation, it'll just pick it up and you pip install, upgrade this, and you'll get the newer ones, which I think is nice, like kind of like versions, your security. So yeah, it's really easy to use, and I dig it. So even if you're a do it yourselfer,

48:44 it's a good place to learn all these things. As I mentioned, there are many in that list of things that they do that, you know, they will not on my writer at all.

48:52 Yeah, so yeah, like the iframe one was not on my radar.

48:55 Yeah, me neither, right. Yeah. So very good project.

48:58 Yeah. Cool. All right, Number eight, number eight.

49:00 So htt. Pi is a very nice project. So we'll use to see when we look at tutorials, people use curl to show how to send a request on the command line. And curl has a somewhat unfriendly structure, especially when you need to send API requests to have JSON, a JSON payload. So what I've been using for the last few years is this Python project called HTTP by HTTP IE. And that is a much friendlier command line HTTP client for mostly for API use. Yeah, I love this package so much. It's one of the first things I install on a new server, it is so much better than curl. I almost never install packages in the global Python. I always create virtual environments. But htt pi is in my global Python because I always use it even if I'm not In a Python project, so I always want to have a copy of it readily available on my command line. So for example, if you need to send headers, there's a syntax where you just use header name, colon, and then the value after you put the URL, if you want to send JSON variables, instead of the colon, use an equal sign. And there's a number of shortcuts that you can use to create an HTTP request very easily. And not only get requests, you post and put in all the harder ones, as well.

50:32 Yeah, so once you install this, probably in your semi global namespace with a dash, dash user type of thing, then you have two commands on your terminal, you have HTTP and HTTPS, and then you just give it a URL or whatever. It's really nice,

50:46 right? It's actually the method and then the URL. So you can say, post, and then the URL. And then you add your headers and your variables. and off you go.

50:53 Yeah, and one of the things I really love about this is the response is color coded like, like a code editor. Right? So you get like syntax highlighting on your responses and on your headers, Cookie values, and everything is great. It's very nice. And I really use curl anymore. Now. Yeah, same. Love it. All right, number nine, I talked about these new frameworks coming along, because flask and Django and pyramid and so on, don't inherently support async. io. And a lot of them are growing to do that. But

51:23 But a lot of people want to use async. io with flask. I think you had Philip Jones, on your podcast at some point to talk about this. Yeah, he went and created from scratch, a clone of all the flask classes and methods within those classes. So basically, he created a full clone of all the flask API's. And that project is called CT eyes. The difference with flask is that it runs on async. io. So you can create a sink view functions. I believe at this point, he has even added some support for for some flask

52:02 extensions, it's almost entirely compatible with the extension system as well, he said, so I don't think it's 100%. But most of the common extensions will still work with Court, which is pretty cool.

52:12 The common extensions that don't do any any blocking work, then, yeah, they will work on court. So it's definitely something interesting, is actually involved in this effort that's starting to add asyncio support to flask, as well, there's a pull request to first pull request, I don't recall if it was merged already, but it's it's close to be merged to add first shy implementation of asyncio support within flask. He's involved without effort. Otherwise, if you want to have full support for asyncio today, using a very familiar flask and all the flask features, then quartz is actually a very good, very good choice.

52:56 Yeah, it's a super good one, all you have to do is replace the word flask with court. It's a little case flask, it's lowercase cord. If it's uppercase flask, it's over his core. And then you have the API, you do have to get the Zen of asyncio, and async and await and all that, which is a different way of thinking. But it's super awesome. Once you get it. Yeah, very, very nice stuff. I guess that'll just kick you down the path to go. Okay, well, now I need to figure out how to do async SQLAlchemy or async Redis, or async. io. It's right. I mean, it's like a, it's a late layers of exploration to take full advantage of it. But it's very, it's a very cool framework. And I'd love to see it part of flask just proper not have these two projects,

53:35 it's gonna take some time to redesign flask to to be fully asyncio compatible. But yeah, the first steps are there. And CT for now is a great option. If you really, this is interesting, it used to be that you will think from the side of standard Python, and async, io will have very few libraries that you could work with. Now, there are starting to be libraries that you want to use that only support async. io, you have a flask application, and you want to use some asyncio library. So going to court will be a good option, in case

54:13 and you talked about building kind of microservice c type of things as well. And in that world, you're waiting a lot on external systems. And when you're mostly waiting on other things asyncio is like It's like

54:24 magic, right? It really shines. Yes, that is the use case. The only one if you ask me. That really makes sense. Because you can scale your little service 10s of thousands of clients. And since most of them are you know, most of the time waiting. It can do that like like nothing else. It's really really nice.

54:44 Yeah, super cool. All right, you have the last one semi last one number 10. Here is yes, something in the same vein but not the same. Tell us about it.

54:53 So number 10 is so let's say you you like asynchronous programming you You're not ready to go full blown asyncio, you have a flask application, you want to take advantage of asynchronous programming, what can you do? What a lot of people seem to have forgotten is that there were many async frameworks that existed from before before async. io. And there are a couple of them that are continued to be supported. And they still run really well. And flask supports them always supported them. And they do that in particular, I have experience with our G event and event LED, and these frameworks are, they have a different philosophy compared to asyncio async. io wants to make it very explicit that you are writing asynchronous code, you have new language, keywords, async await. So both Gln, Evan lead, look at this from a different side, they try to make normal code that you're familiar with become a synchronous under the hood. So you write the code in the way you always done it. And they implement or re implement all the blocking functions in the Python standard library. Using asynchronous functions, they use the same interfaces. So these frameworks are intentionally supported by flask. So flask recognizes if it's running under these frameworks, both are based on a package called greenlit, which is the core technology that makes this possible is a native code extension or plugin for Python that you install with Pip. And if you're running under greenlands, then flask makes everything work the same as if you were working with normal threats. I personally have been using both g event and Evan lead for many years on flask applications with very little problem, boss.

56:52 All right, well, that's when I didn't know about. So that's,

56:54 that's another option. I bet it'll work great with pyramid as well. Yeah, probably you get a new implementation of sockets and threads, and you know, all those blocking functions in the standard library that are asynchronous. And you call them in the same way. Yes, it

57:10 was way below the layer. Yeah, like the framework wouldn't even know. Right, right.

57:14 So you can use flask, you can use requests, you know, all those libraries that do threading, networking, all those automatically become a synchronous by installing this library and using it as a server. Very cool.

57:26 All right, well, that's an awesome one, I'm gonna look into that. Now. That's our 10, I wanted to throw it just really quick and let you just riff on this one, because I feel like this one is so in the wheelhouse of flask. And yet, I don't nearly see it spoken about enough blueprints, blueprints.

57:41 That is a good point. When you're building an API, you probably, if you're doing micro services, you probably use a full application for each service, when you're building something a little bigger than than that than a micro service, you would like to structure your application in a way that has, that's modular, right, you

58:01 don't want like a 3000, line app.py file,

58:05 right, probably

58:06 definitely don't want that. I don't want one. So flask has this concept of blueprints, which a lot of people think there's something very complex or magical, or sophisticated. And it's really a very simple idea, which is to partition the application in different modules or packages. And you create a blueprint, which is like a mini application, that then you plug into the flask application. So you create all these application subsets, which can be a collection of routes, templates, and static files, you build this bundles, you call them blueprints, each one can be a module or the package, and then those by themselves, they do nothing. But at some point, when you create your flask application, you can plug them into the application. And then at that point, they become active. And then you can get all of those working together to form the application.

59:06 That's pretty cool. I really like it. So if you had like a site, and you had, let's say, seven or eight view methods that had to do with account management, right, you would have maybe have an account module in there, you'd have your view methods. And instead of trying to somehow reverse past the, the app, itself that you've created, but then also bring that back into the app UI. It's sort of circular, you create the blueprint, and then you put say, at blueprint dot route instead of app dot route, and otherwise, it's basically the same. And then then you've got a much

59:37 nicer participates looking application. Yeah, differently. Most applications that I built, they have at least two blueprints, one that I called main, which is the core logic, and then one that's called auth that performs all the authentication, right. And one nice thing about working in this modular way is that if you wrote an auth blueprint, very likely you can take it from one One project to the next.

01:00:01 Oh yeah, that's a good point, you

01:00:02 can make it into a Python package that you can install with Pip. Some extensions, some flask extensions are actually blueprints, I hadn't

01:00:08 really thought about it that way. That's cool. Because then you just go from your package dot blueprint, you just go app dot register routes out the package dot blueprint, and boom, it's good. That's a really interesting way to modularize.

01:00:21 Yeah, the one that I've used just this is a flask bootstrap, which gives you access to some nice helpers to deal with the markup and the JavaScript required to do and the forums for the bootstrap framework for the client side. And that's a blueprint. So when you register the extension, the extension, the only thing it does is it registers the blueprint with your application. So plugs into your application, and then off it goes. So it's actually a nice way to develop extensions for flask or, or your own reusable packages that you want to use in your your own solutions are similar uses for blueprints, very cool,

01:00:57 aren't we go? We're pretty much out of time, I think at this point. So those were really, really interesting. And I think people will get a lot about out of those ideas. I'm sure.

01:01:06 Most people, at least one of those is new to them, right? Hopefully one or two is Yeah, for cool. I know there was one near to me. Let's secure the money. So I get something out of it to me as well.

01:01:19 Awesome. All right. So really quick, last two questions. If you're going to write some Python code, what editor Are you using these days, I use

01:01:25 three editors. So I use PI charm. Sometimes I use Visual Studio code. Sometimes I use vim, sometimes, you have to pick one. You have to pick one. And this is also I'm sure it's going to disappoint a lot of people. I think my favorite is vim, okay. And the reason is that I work a lot on remote servers. And it's really inconvenient to set up one of the larger IDs to work remotely. It's sort of an annoyance, I just want to SSH into a box, and then drop my config file for vim. And then it works exactly like it works locally. And vim has a is our learning curve. But once you learn it, it's actually very efficient. And it has Python plugins that give you some of the things that you get on the on the more elaborate IDs. So very cool. I have to think that vim is my favorite. Also, a lot of somebody may choose Yeah, yeah, a lot of people don't like that one. When I do my tutorials, my tutorial videos, I use vim, the reason why I use vim there, it's not because I like it. It's because I know that's the least likely editor that people following my tutorials will be using. And I want to force them to think about how to translate what I do, instead of just copying every keystroke that I make. So I use the editor that I think it's the least likely to be known by my students

01:02:51 or interested in philosophy. So since you brought up vim, I have a vim joke for you. Okay. How do you generate a random string? You get a first year computer science student to open them. And then you ask them to quit to quit? Yeah.

01:03:10 So I did two videos that are actually very popular, showing how to set up a flask application with PI charm, and then I did another one with VS Code. I'm going to do the same with vim. It's gonna be very fun. It's probably going to generate a lot of hate as well, but I'll take it.

01:03:28 Yeah. Why did the comments disabled on YouTube for this one? I don't know.

01:03:32 I think people will be surprised. Because, of course, the very first thing that I'm going to show is how to quit, of course, but you know, you don't have to learn a lot of things to be productive with them.

01:03:42 Yeah, very cool. All right. And then notable pipe package.

01:03:45 This isn't a p ypi. t mux is a package that I use a lot with Python. And in general, when I work on the command line, okay, what does it do? It's a terminal multiplexer. A lot of people ask me what when they see my videos, this is another one that I get very often, they see me, you know, happily punching keystrokes. And suddenly, the screen divides into two, and I get two terminals instead of one. People don't understand what happened. And this is T mux. demux is a very nice package. There are actually packages on pi pi, that allow you to talk to T mux. And make it even more integrated into your Python workflows. But the packages is a native utility that you install with comes with one two, there are one two packages on the Mac with brew on Windows and Chromebooks, you can use that it runs perfectly on the Linux emulation systems and basically allows you to to create multiple terminals in the physical space of one. And one thing that is very nice, if you have it installed in a remote server is that when you exit the server, those terminals remain. When you SSH back into the server the next day. All the terminals are there exactly how you left them.

01:04:59 I see. So whatever you You're up to it's still around.

01:05:01 It saves all the terminals. Yes. Yeah. Very cool. So so that will be my nice package.

01:05:06 Yeah, that's a great one. All right, final call to action. And people may be working on flask for a while they want to apply some of these tips, what do you tell them

01:05:14 something that's very important to me. I had a lot of great stories that were a result of me sharing, you know, when I started on my blog, and then conferences, who knows when we're going to do conferences again, but so sharing is I think, what helped me get to where I am having a job that I love, my recommendation would be that using these tips, or all the tips that you get from other sources, and when you come up with a solution, share it, you may think that it's something that everybody else will, you know, could easily come up with,

01:05:49 no, they already know it, I don't need to talk about this,

01:05:52 I don't need to talk about it. Well, you actually do, there's always going to be someone who's, you know, on the same path you are, but it's, you know, a few steps behind, that will benefit and you will help them progress in the same way that you you are making progress. So you should definitely start writing a blog or videos or tweets, you know, however, in whichever way you are comfortable, but start sharing. And what's going to happen is that all that volume of work that you're sharing over time, is going to speak for yourself. So you will not have to take so much effort in showing yourself to prospective employers or contract in our friend tracking user groups, conferences, when you apply to a conference, all of that thing that you produce a little bit at a time is going to speak for you. It's going to be your best advocate. That's what worked for me. So

01:06:48 I think everyone should definitely and I think also it's a great way to learn, even if you don't totally know, because people will say why are you doing that? Why don't use this package? Or you could actually do this other extension or like or the reason I didn't do that. I didn't know. But now I know. Right? Thanks for telling me right. Next time I'll do I'll do something different. Right. So yeah, it's great. All right. Really great to catch up with you. Thanks for coming on and sharing all these tips. I think people will find them very useful.

01:07:10 Thank you so much for having me.

01:07:11 Bye. Bye. This has been another episode of talk Python. To me. Our guest on this episode was Miguel Greenberg. And it's been brought to you by century and linode. Take some stress out of your life get notified immediately about errors in your web applications with century. Just visit talkpython.fm/ century and get started for free. Start your next Python project on the nodes state of the art cloud service. Just visit talkpython.fm/ linode li n o d, you'll automatically get a $20 credit when you create a new account. 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 the 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 pod catcher and search for Python. We should be right at the top. You can also find the iTunes feed at /itunes. The Google Play feed is /play in the direct RSS feed net /rss on talk python.fm. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Don't get out there and write some Python code