00:00 gengo is a very popular Python web framework. One of the reasons is you have these many building blocks that drop in for large sections of your applications. Need a full on admin editor back end, there's a few lines of code and boom, you have a basic table editor. This appeals to many people. But for those of us, myself included, who appreciate lightweight frameworks, where you choose just what's included and pieced together after best of breed components can find this a turn off. This week, you'll meet Julie element and Mark Levin, authors of lightweight Django who are here to dispel the myth that Django apps have to be built out of large building blocks. This is talk Python to me, Episode 88, recorded November 21 2016.
00:41 developer, developer, in many senses of the word because I make these applications, vowels and use these words to make this music
00:51 constructed.
00:53 When I'm coding another
00:54 software design
00:56 cases, it's about design patterns, anyone can get the job done. It's
01:00 the execution that matters. Many interests.
01:03 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 talk python.fm and follow the show on Twitter via at talk Python. This episode has been sponsored by gocd and pi up that's right pileup that IO has joined the show as a sponsor this week, thank them both for supporting the show by checking out what they have to offer during their segments. And
01:35 Julia mark, welcome
01:36 to the show.
01:37 Thanks for having us.
01:38 Yes, thank you.
01:39 Yeah, you're welcome. I'm super excited to talk about your book, you guys are doing some cool stuff. I'm really looking forward to talking about this combination of technologies. I mean, we're going to talk about Django was going to talk about backbone, we're gonna talk about WebSockets, Redis, tornado, all sorts of cool things. And I really like the way that you put them together. So we'll have a good time talking about those. But before we get to that, why don't you tell us your story? Like how did you get into programming,
02:03 I think that my love of programming really started when I was pretty young. And I was very fortunate to be able to learn how to use logo on Apple TV in first grade, and just kind of like being able to play around, right. So having the ability and to do that really started to get into it there but ended up going into art. And slowly after graduating from college, realize that he can't really survive on making art decided to go back to the thing that I was really interested in since I was a kid and started doing web design and development, which back then there wasn't really programs for it. And so I ended up getting a job in internal marketing agency in a small company and really learned there on the job. And shortly after that got a job at Hallmark cards, whereas a interaction designer, so do a lot of thumbs up cards,
03:01 things like that.
03:03 So yeah, yeah. And but then I am at this guy at South by Southwest Interactive bajillion years ago. And he was like, so have you heard of Django? And I said, No. And he's like, you live in Kansas City. And you live so close to Lawrence, Kansas, and you don't know what Django is? And I said, No, and he's like, you got to go work at the Lawrence journal world, I'm sorry. And that person was Simon Willison and introduced me to a few people. And I ended up working there for about a year and just learned all about Django and contributed to the actual project and that's when I really started working in Django was
03:49 was then this really cool way to get introduced to basically go to the birthplace right.
03:54 Yeah, yeah, it's really, really amazing time for sure. Because that was like 2007 2008 when I started working there and so yeah, like three years after it had become an official open source project,
04:10 right. It was just some kind of internal thing it was actually recognized as this this big project. Yeah,
04:15 yep. Yeah, by then. Yeah, nice. I
04:17 love Lawrence, Kansas. I went to university there and enjoyed my time in the town.
04:22 Oh, Rep. Talk, Jae. Ha
04:24 ha ha, yeah, right on right on. About You, Mark,
04:28 how'd you get into programming?
04:30 I father programmer, a long time maybe your dad IBM, my older brother always loves programming. So I resisted. Being a programmer, being a stubborn little child, wanting to do something on my own. I always kept coming back towards it, studying math in college, and I dreamed about being a professor. I don't know why I dream about being a math professor. But that's what I that's what I had.
05:01 There's a lot of cool stuff about being a math professor, job opportunities, not necessarily one of them.
05:07 I guess I just really love like tweed jackets and elbow patches. And that's what I envision my future. And so I continue doing math and in graduate school, and a lot of programming, the code comes into doing some applied mathematics. And as much as I resisted, again, like I just kept coming back to it. And when I left graduate school, I started looking for work. What can I do with this, this math degree that I had, I was in New York City at the time. And I got into finance, I just got sucked right in to doing crazy math on Wall Street. And it was fun, exciting for a time, we were doing some really cool stuff over the counter derivative pricing wasn't as flashy as Michael Lewis sort of draws in his books. But we were, it felt like we were on the cutting edge of financial math to some extent. But there was a little bit of a financial crisis, you may have heard of Anno 2008. Nine. And while my company was really negatively impacted by that many of our clients were in a really stressful time to be pricing in such a volatile market, are having a lot of questions about our work, a lot of really bad market data diversity through in that process, a lot of my work with about automating what we're doing, collecting data, parsing really messy files, and tried to turn it into reasonable data use. And we were doing weird things in VBA. Visual Basic. So yeah, how much of the world runs on Excel
07:01 as the quote, programming,
07:04 back end video, ever believe. And then we also had applications that were written in C++, and they had nothing in the middle. And I started exploring sort of scripting languages, but I started working at I started learning. I started learning fertile. And I had a friend from graduate school who was pursuing a PhD. And he said, Forget everything you know about Perl and learn Python. And I took his advice. And I did. It didn't stick at work. My boss wasn't really interested in change. But it stuck with me. And I kept playing with it for different roles, grouping tasks, and automating boring things and solving math problems with it. And when I decided to sort of leave your my way, and started pursuing careers outside of finance, started looking at what I could what else I could do with this sort of hobby. And
08:03 I found good for anyway, yeah, what's this Python
08:05 for, and I have all this free time. And I just, we just quit, we just left came and stay with my family at North Carolina run from build myself a website in Django, and I was having a blast, the little brown tracking thing for running. And yeah, I was still searching for jobs in finance. And then eventually, I thought, maybe someone just pay me to write stuff in Django. And strangely enough, I found her contract contractor posting, cactus group was like, two guys working in office in cargo at the time, and started working with them. So got one contract, finished that to another, and eventually got hired full time with them. And I've been doing full time Django development with them for almost seven years now.
09:00 Wow. That's really cool. I like how you kind of just kept going and looking for that Python opportunity to work in the space you wanted to. And eventually it worked out. That's great.
09:12 advice to forget her all and learn Python was best advice someone's ever given me.
09:18 Now we come to about a year and a half ago, you guys created this book called lightweight Django. Julia, what's the story with your book?
09:26 It was about a year and a half ago. I think it was like two years ago,
09:32 Mark. got published. Yeah.
09:34 almost two years to the day. Yeah. Sorry. No, don't
09:38 be sorry. I just was kind of like, no, it couldn't have been that long, like 10 years ago. So yeah, come up for the idea for the book. So I think that Django is a lot of people look at it and they're like, Ah, it's so big and it's like a dinosaur and can't use it. Because it's there's too much and I don't need everything that's in there. And I don't know, I just talked to mark about that when I, I like I would hear this. And Mark and I were both working in the same place at the time. It's
10:12 like, I don't know that I agree with this, there's
10:14 got to be a way that we can show people that they can use Django and this is, this is also the time of flask sort of coming on the scene and know people started making all these little flask apps and then all of a sudden, they're like, Oh, I probably should start with Django. I
10:30 shouldn't have done doing all this work.
10:33 Yeah, like made all these class apps and then Rosie's Django, Diego, so. So yeah, we kind of talked about it. And we were speaking at a conference or sia OS con.
10:46 And I was like, Listen, what do you think about writing a book?
10:51 I've got way too much time. Let's just get rid of that.
10:56 I remember that feeling you she was just blurted out one. Coffee or drinks or something, we should bring a book. And I think I just said, Yeah, I had no idea what we're gonna write. Oh, you
11:09 did not know. You were like, you were like, I don't know. You were you were smart. Three months. I was like, we could do it. It's fine. We could do it. And you're like, let me think about it. Remember, I remember you're like, yeah, I gotta think about this. So. So yeah, and like calling it lightweight was sort of the antithesis of what people refer to Django. So
11:32 like, I don't want to use that. Yeah, rather than let's plop in Django ORM. Let's plop in, like an admin back in all these big building blocks, your book takes the approach of saying, basically, let's see how you can strip this down to a very small core, and then build up your own, like starter templates and tweak it however you need. Right. And you're also bringing together a lot of interesting technologies that are not just Jenga, Mark had you pick those?
12:02 Pick, the ones that were most familiar with, either from projects that we built are of your professional year, projects are built on the side, and experimental projects, one that we knew would work together when we had some familiarity with and that had some of the same sort of staying power, as Django did. A tornado is one that I really like it's been around for a long time. And if it does this one thing really well. And it's not flashy, it's stable and boring. Just like I like my technology.
12:41 Yeah, tornado plays a really important role. And definitely, when we get to the eighth a sink section, war, or the real time web section of this conversation, it will definitely come back to it. So when you guys wrote the book you have in mind for it, Julia, like, Who is your ideal student? Or we should read this, but
13:03 definitely an intermediate. I don't know, I've had this conversation with a few folks like, beginner, intermediate and advanced, it's like, Is there really an intermediate is there really like, it's, it's it's like, so when it comes to, I think it's more like people who have actually built a Django application, and have some sort of familiarity also with JavaScript. So I think that that is part of the audience, the people who are also in, like, have this infrastructure, they they're already using Django, they already have it as part of the applications and whatever product or platform you're using. And they're kind of locked in. And they're seeing all these newer technologies kind of come out. And they're like, looking at the longingly. And they just don't understand how to kick them all. And so, no, I don't know, I think it plays to a couple quite a few different audiences, ones that need to be convinced to use Django that may be how it used it before that, but programming other languages and other web frameworks. Okay, yeah,
13:59 I do think it's interesting to see how these pieces fit together. And you know, Mark, to your point, it's really challenging to choose those. So you're choosing Django, obviously, but you're also choosing backbone, and Redis. And some of these other things, and especially in the JavaScript, front end space, that that's a real topsy turvy world, right. And so, you know, by the time you're done with the book, you don't want the framework to be passe, right?
14:23 I don't know, I think I've had a couple of folks ask me why we chose backbone, I think Mark could have very well, which is just kind of like boring and stable things that work. And I feel like the backbone is pretty straightforward. There's nothing flashy or fancy about it. So when it comes to those things, I don't know. It's like, what's in fashion right now. It works. Yeah, you
14:50 don't want to get caught with bell bottoms in the 80s. Well,
14:54 I think it's also a matter of, it's so basic, simple and straightforward. A little A lot of the concepts in backbone can then be played out in other other front end frameworks that your JavaScript frameworks that you're wanting to use on your applications, right? Like, it's not going to be too dissimilar than something else that you're going to choose whether it's going to be react, which is the thing. I think at the time of the this book, it was Angular, and people are starting to kind of like, look at knockout.
15:23 But I don't even know, I don't really remember the debate, I think we had was Angular versus backbone or Ember. That's right. Yes, November, Ember is really popular in the Ruby community that follows a lot of conventions there. I don't see us quite as much in the Python community, maybe that's just my own bias showing through the concern we had with Angular was the steeper learning curve. And we kind of wanted to focus more on how do these pieces work together right away. Let's try to teach you Angular and Django at the same time. And I think that's where backbone kind of one out out of those three, that it had a push out in her. And it sort of moves the same technology, or the same terminologies as Django did back end and play very nicely together, which works well, for both.
16:21 Yeah. And I think in the end, like I said, it's it's pretty simple. So if you decided you wanted to go use Ember or something shiny, new, like a really or whatever, just, you know, you could translate it pretty straightforward. If you knew that other framework.
16:32 Well, not only that, but just showing how do they connect? Right? Like, how do you connect these two things together, which I think is a mystery for a lot of people that haven't shown that translation? And then oh, that's how you do it. Yeah, absolutely. I
16:46 think that's a lot of the key lessons that are takeaways from your book, or this piece connects to that piece, in this way that can piece connects them to this piece in that way, you know what I mean? So you guys are using Python three, for your book. And that makes me really happy. I love it. Whenever I see Python, three Sufi news, and I've got some good stories on Python three coming up. But was that how much did you guys think about that? Or how much just go? Yeah, Python Three, two years ago, it was a different time that just now,
17:15 I think at first, they sort of thought we'll do dual code base, we'll do two and three. And just see how that goes. You know, we written a lot of reusable components that support both than familiar with doing those. But as we started working through that, there's a lot of explaining, why do we need this? Why do we have that. And it got a little clunky, we spent a lot of time explaining the differences between Python two and Python three, instead of the message that we want to give, which is, you know how to use Django with backbone? Or how do you do WebSockets with Django? How do you build a single file application with Django that we wanted to teach people are getting caught up teaching people the difference between two and three. So in the end, we abandon Python two. And so the best people shouldn't be building new applications from Python two, hopefully, they're not going to feel strongly about that direction. They'll have a lot of support from another O'Reilly author Harry Percival, who had just published a book that was Python three only, and he felt very strongly about that same direction. So we have received some criticism for making that choice. And someone called our use of Python three academic at one point, but they're even two years ago, we were building applications in Python three are here professionally for our clients. So that's definitely the way to go. Wouldn't that just serve as to read a book even two years ago, based on Python two,
18:49 to add to it as well, it's sort of like trying to push the community forward. Oh, nudge, right. Yeah. If we only read it in three, and that's it. It's like, you just gotta learn it, and gotta keep moving forward. And I think sort of like eating this pipe on to usage doesn't help towards moving everyone cards.
19:14 Yeah, I think all of us that are doing stuff in public, if we can take these small steps, they add up to make a big difference. in aggregate, you know, one of the things that made a big difference in the Python three usage measured on pi pi, relative to like the year previously, or whatever, was actually to do with Django, and they switch the default language of their documentation and their tutorials to Python three. And that actually made like a pretty measurable difference in the amount of Python three usage, like as seen from pi pi downloads. So let's talk about the first part, Julia. So one of the things you guys start with is the world's smallest Django app. kitchen was the story of this.
20:01 So it's sort of like fasching. That concept of this is following the instructions of how you actually build an application like doing the polls tutorial application. And this is the way you have to do every Django app. And a lot of what that chapter is, is saying, nope, you don't, you can actually just have one file
20:25 to do it all.
20:27 So when we're trying to think of the progression of the chapters, that was something that I kind of starting with, like, I really like how you were saying, and you've got the concept how the chapters build off of each other. So we start with the tiniest little thing, build. So
20:46 how much of that is like a reaction to flask coming along, saying, here's our one file? That is the web app, and you thinking like, wait, Django can do that. It doesn't by default, but it can.
20:59 Totally, let's talk? Yes, of course, it's, I think, and it's funny, because I've had a lot of people tell me, and I'm probably mark as well, I kind of come up and be like, after reading just the first chapter and like, I never thought of it that way.
21:18 Never. Yeah, it's it is in our scene, like, you know, the starter projects there. And you know, like pyramid has it scaffolding. And the thing that comes out looks really complicated when you're new. Like there's like, Why are there so many files here and all this stuff wire together, but it's easy to like, see that as required, rather than just the conventions? This community's following, you know?
21:40 Yep. Yeah, totally.
21:42 So another thing that you bring up and I thought was really interesting that you covered here were components or parts of this thing called the 12 factor app. What's the 12 factor app
21:51 for factor is pretty growing popularity, your way of sort of building and deploying applications through a set of principles around what makes an application easy to deploy, and scale in multiple environments. And we didn't want to preach too much, I guess about that methodology. But you talk about some of the challenges that people face when they are using Django. I think this question of how do I have multiple settings files comes up all the time. And certainly for that sweet spot of our audience of someone who's maybe build something and wants to deploy it, make it real, you know, put it out on the public Internet, then they come with, well, how do I, how do I configure this for my local development and for this production environment, and 12 factors, one way to do that way that I think works fairly well. And so that's sort of the direction we tried to nudge people in.
23:02 Yeah, sure. And I thought it was pretty cool. I one of the philosophies you're talking about there is to try to have the minimal amount of deviation from like dev to QA to prod. So the thing you're working on is close to the real thing. Right?
23:17 Absolutely. And making those differences, obvious, sort of seeing which settings can be changed, which ones can't, is that
23:29 Yeah, absolutely. So the next section that I thought was interesting and worth talking about, it's this part where you kind of speak to stateless web applications. And you say that much of the focus in Django is about building reusable applications that can be installed and configured for like a Django project. But that could get really complicated. And so you talk about breaking your web app into like, small composable services. And I think that's a
23:56 that's a recent trend that people have been leaning towards wanting to do micro service architecture, you can't see my air quotes, but they're there. And so again, I think that's where people were reaching for other frameworks. They felt accomplished this better. And I want to give her the story that we wanted to tell was, this can be done in Django, two, you don't have to throw away your existing Django knowledge to build these types of applications. In fact, Django has a lot of utilities that make it easy to build these types of applications are my favorite things about that chapter in particular, I feel like we do a really deep dive into some of the HTTP caching layers that Django provides, you know, those utilities that Django provides. And I think that's really important for those types of applications at scale.
24:53 I agree as well. Like, how much do you feel that developers are spending too much time chasing The shiny new thing. I feel like you know, especially around things like Node JS and the front end frameworks, it's like, well, that's six months old, we should be doing something different. Now you're doing it the wrong way. It's old. It's like, wait a minute, Isn't that too quick?
25:13 I felt like it's not necessarily because developers are always trying to strive to be better, faster performance. And think that's we're always trying to look have that optimal utopia of combination of things. And combination of technologies. Right. So I think that's a that's a big part of this. Yeah, I
25:35 agree. It's a real challenge, because it's fun to work on the new shiny stuff, right. But at the same time, if you build an app that takes a year to build, you don't have like three different technologies mixed in, I guess, there were seasons, technical seasons. So one of the things you guys did in this stateless web app section was you created like a placeholder image thing for prototyping out the site, you can say, Well, I don't really know what image the graphic artists gonna put here, but it's going to be 200 by 300. So give me a 200 by 300 image, which is pretty cool. And use this package called pillow. People love to learn about new packages on the show, tell people what pillow is
26:12 pillow is the Python imaging library. And it is a work of allowance really, you know, module. So it's really, I think the the golden standard for Python image manipulation. If you need something to either modify or tweak an existing image or something like we're doing, which is generating new images, it's your go to
26:57 this portion of talk Python to me is brought to you by gocd. From thoughtworks. Go CD is the on premise, open source Continuous Delivery server. With gocd comprehensive pipeline and model you can model complex workflows for multiple teams with ease, and go see these Value Stream Map lets you track changes from commit to deployment at a glance, go see these real power is in the visibility it provides over your end to end workflow, you get complete control of and visibility into your deployments across multiple teams say goodbye to release a panic and hello to consistent predictable deliveries. Commercial support and enterprise add ons, including disaster recovery are available. To learn more about gocd visit talkpython.fm/ go CD for free download, let's talkpython.fm/ g OCD. Check them out, it helps support the show.
27:56 Julie, the next thing that you guys did was you said one of the popular trends is to use something to generate like a static site. So maybe it's data driven. But the thing you actually want to deploy to the server is static because it's easy to scale, cheap to run and things like that. And so you you should how Django can actually be used to build static sites, right
28:16 static site generators, thing that I in my current role I pretty much that is the thing that we we use a lot in prototyping. And a lot of chapter is about is about doing things like rapid prototyping, right? So you have a client or even dislike, want to build something quickly, or you want a blog and you don't need a database. That's something that a lot of go to particular things like Are there other frameworks like Jekyll Pelican, and a bajillion others that I don't know that so there's one, two ones that come to mind. But there's a way that you can do this with Django. And again, going back to the user that is sort of locked into using Django, on whatever platform they're on. And then also wants to be able to do something like I said, generator with they're kind of, they're using Django, so it's like showing how you can actually do that.
29:12 Technologies. So
29:13 yeah, that's neat. And some of the stuff that you covered in there. I think, when people are new to web development, they don't really know about it, or they don't pay attention to it until it becomes challenging, let's say. And you were showing how you can do sort of bundling and minification, cache busting all that kind of stuff with Django, right? That was cool.
29:34 Yeah, and asset management too, right? Does a huge thing, like something I've been thinking a lot about lately is asset management in general, and how, how it plays across all these different frameworks, right? And all these different things like how do we compress files, how do we take things that need to be compiled from one thing to another copied over and that's something that you know, just showing this one How to do that, in general, I think has a huge value. So this particular chapter being able to show not only how to build something in Django, like a static site generator, but also, like asset management, which, you know, Jake has always been something that I just love because he has so much freedom. I feel like it doesn't there's not a lot of rules around it, which is another theme of this book, right? Like this underlying theme. There are no rules breaking apart, smash it just using one file, like create a static site generator, whatever. Yeah. Exactly. And that's something that you know, I love about the framework, and kind of wanted to show here.
30:40 So yeah, I thought that was that was really interesting. So then mark, you started talking about how to build restful API's, because if you're going to have a single page app, a spa, is going to be pretty boring without some server side communication. I
30:57 absolutely. And I think we have great tooling in the Django community for doing this and compensated work relentlessly on Django rest framework. And we're all better or his work and contributions. So yeah, we wanted to show off sort of how easy and fun and elegant it can be to build a RESTful API in Django. So what do you think people get hung up? Building like HTTP API's? Other than calling? Maybe it restful? And it's actually not they get a fight about whether it's truly restful? Did I mean, like, what do they get hung up in just about, like, mistakes that you see them making? Well, there's certainly a lot of debates that people like to have. And I certainly like to have my fair share of those base, as well. But mostly about wanting good support for validating data that comes in and generating responses to go out. And ideally, being able to accept different formats on both ends, being able to take in JSON and return JSON, being able to take in XML and return XML, or gamble or whatever their favorite means of communication is. So I do think that people get hung up on trying to make things perfect or fit some vision of what they feel restful is, but I think, rest framework in this community gets you a good percentage of the way without a lot of without a little work.
32:31 Yeah. And the fact that there's that nice framework that's really ubiquitous in the Django space makes it there's a lot of shared knowledge on that right. That's cool.
32:39 Yes. And great compliment on utilities is in call themselves great framework. And I think it's true, because other people are able to build off of it. It's not what's cram everything together everything that anyone could ever want. It's what's given extensibility and lead, other people in the community, add things that might be missing from the core. Yeah, there's just a lot of great activity going around that project.
33:07 Yeah. Okay. Yeah, that's really cool. One part you guys were, I don't remember what part of it I think it might have been this section, where you were using the forums, classes for validation that you would typically use for HTTP, get post type forms, and you are applying for validation? Was that the restful part? We did? In the stateless application, we
33:32 actually validate the incoming path expressions.
33:35 Oh, right. Right. Right. for the, for the like, the the sizes of the images and stuff. Yeah, I thought that was cool. Like, why do you tell people just real quick, how is more flexible than say, just, you know, straight ACP angle bracket form?
33:50 Oh, that's, again, a big theme of the book. And maybe it's an unspoken being, but it was definitely a big motivator for us is, is showing using Django for pieces of Django like it's a collection of libraries rather than a framework. That's something kind of taken us as needed. And the forums library is the name of the forum section. Django is an amazing piece, not just for the HTTP aspect computer does help you with sort of rendering HTML forms on the front end. But the biggest piece is about that validation. And we'll use forms to validate incoming csvs all kinds of crazy stuff. And it's got a really simple API and a nice declarative view of the fields that should be there. And then it takes a dictionary and it says, this dictionary is valid or is not valid. And it has methods for cleaning data that it comes through and right and it's not just
34:55 this value type has to be a positive integer. It's like this This has to be an integer between one to 10, or something like that, right? Like, lots of
35:04 nice little rules and whatnot. Absolutely. And that dictionary, that blob of data doesn't have to come from an HTTP request. They're really decoupled in that way, that dictionary can come from anywhere. And I think it really speaks to your maintainers of the Django project to build something that's as flexible is,
35:25 yeah, it's excellent. It's very nicely decoupled. Cool. So I want to make sure that we spend some time on the last third of your book or last quarter, I guess, quarter, but maybe telling people about the middle party, so they know, kind of what kind of apps you're building and so on. So Julie, the idea was, you're gonna model some kind of like Scrum Kanban, board type thing, right?
35:46 Yeah. And we were trying to come up with application like what we would use in our day to day, and basically how that would tie together, but also like, how can we sort of start with like a simple, super simple part of it, right? And build from that. So the sort of the concept of why we're going to build a like a Kanban. board.
36:09 Yeah. So basically, with backbone, you build a Kanban board, and you can edit it through Django and so on. And then you get to this part where like, well, it's cool that we have this board, but it would be way cooler if we could edit it together on the web. And so this brings us to a section called real time Django, like, tell us about that.
36:33 Yeah, real time Django.
36:35 So what is real time? Django that? That sounds cool. Sounds fun.
36:38 It can be anything. Real time just covers like such a hostess.
36:45 many sins have been committed in the name of real time simulating something real time, right? So this is like, I don't want to have to refresh my browser. I want to open a page like Google Docs or something, right? We can all type and it just it changes as we all work with it. Right? That's the basic theme.
37:03 Yeah. And like also bringing like this, that whole concept of like, you don't think Django can do this. But it can, you know, yeah, that's
37:10 really, really excellent. So you guys run down some of the options for real time communications, you're like, Well, we've got WebSockets. We've got server sent events. We've got web RTC, there's even like old school long polling. And which one did you end up picking?
37:26 We ended up going with WebSockets. And we use numbers out kind of why I mean, the server sent events, or maybe a better map to how we end up using WebSockets themselves. But WebSockets are just better known and better. Browsers supported definitely two years ago, they had much better browser support. Most frameworks that are geared towards doing real time web typically shipped with WebSocket types of support out of the box and server sent events, not and usually doesn't add on. So we went with WebSockets.
38:04 Yeah, certainly two years ago, that makes sense. I think those kind of features have come a long ways. In two years, right. It feels like the html5 stuff has definitely grown quite a bit. From 2013 2014.
38:17 Yeah, maintenance every day, or people just keep pushing and pushing and doing crazier things. And it's cool to see those technologies that definitely mature to where two, three years ago something, say, well, maybe this could be an add on, it's probably not required for your app to really be functional. And now I think people are really gearing towards more apps where it's like, a core piece of functionality that absolutely needs to be there and work for the app to be useful.
38:48 Yeah, I totally agree. And you guys point to a website that I'm a big fan of called Can I use comm? And as you're talking about these features, you're like, oh, check this out on Can I use comm? Why don't you tell people quickly about that, if they don't know about it? That's that's a good resource.
39:02 Yeah, it's a place where you can see if a particular feature is going to work on various different browsers, but not just the browser's actual version of the browser. So if you're not quite sure if this is going to be available, a lot of what I do now is making sure things work on really new the old browsers for many reasons. many good reasons. So yeah, I use that all the time.
39:26 Yeah, it's, you know, the web is always like, a compromise at some level, right? Like, oh, there's this new cool thing. Oh, but it's not supported on IE. Or there's this other great thing, but it's not supported on safari on mobile. And you have to decide, like, do I really want to have a degraded experience for these people like and so on? And sometimes the answer might be Yes, like, for example, if you want to use CSS three 2d transforms the only browsers but that doesn't work on according to Can I use his Opera Mini, and it might be totally reasonable God, I don't care. It's just gonna look bad on paper. Yeah,
40:00 but there's fallbacks that you can actually use these if you want to. Like if you want to go for it and try something there's definitely fall back so you can use so a wreck I encourage those that are listening, like, Don't feel like you can't move forward with this particular technologies. So
40:16 right. There's a lot of times some kind of polyfill you can do.
40:19 Yeah, moderniser is a big one. Absolutely.
40:23 We take just a moment and tell you about one of our sponsors that makes this show possible. This portion of the talk Python is brought to you by pipe.io. Have a website based on a popular framework like Django, you really want to make sure that you're on the latest point release that includes all bugs and security fixes. With pipe that IO, you no longer have to search for updates manually, possibly missing an important update for security vulnerability. When you add one of your GitHub repos to pipes online service, the pipe bot immediately start searching for requirement files, that will send you one big pull request that updates all your dependencies, and the bot constantly checks for new releases on pi pi. This PR contains all the info you need in one place. And your tests will run automatically telling you if an update broke your code in why try today by visiting pi up.io. That's p y up.io. Accounts are free and come with one private repo, if you need more plans started just 499 a month. Okay, so you decide WebSockets. And then the real challenge and I think I wanted to ask you guys about this in a more broader sense, such as the context here book. But in order to do WebSockets, you have to have these long term many, many, many connections back to you know, if your site's successful, hundreds of thousands of browsers, right, and whiskey, and a lot of the Python frameworks, Django pyramid flask, they're not really built to handle the asynchronous web are these long, long, long running connections or ACP to a lot of this stuff? Do you think it's time for like a whiskey to? Or some rethink of how web processing is done?
42:04 Yes. And no, I mean, be nice to get a refresh of something that is definitely geared more towards long your long term connections over HTTP. But I still think that there's a lot of web applications that are still really request reply based, and that's fine. There's always going to be that need, you don't want to throw throw everything out in the pursuit of something that has that support. HTTP two is probably a really good one where, yes, you want something to, yes, he wants me to hold the connections open and make use of the multiplexing that they allow. But that doesn't necessarily have to be exposed at the framework level for it to be useful,
42:55 right as to like, for example, nginx supports that already.
42:59 Yeah.
43:00 So maybe if you're using g unicorn or micro whiskey behind nginx, like your actual data driven Python requests might not do HTTP two, but the rest of it could, I guess,
43:10 yeah. What's interesting or confusing, maybe, in this HTTP two world, a lot of the things that we've been doing and some of the things that we've even touched on earlier, concatenating files and minifying them all together, some of that really means it loses its usefulness. And instead, you want to make those be additional requests. And you potentially want to be able to do browser pushes on your page load. And say in here, all this, the CSS files that are going to come with this page, here's all the JavaScript files, so we can have to unlearn some of the things that we've done. And then and new hooks into our frameworks to be able to make use of features pretty interesting idea, I wonder if Google will start ranking sites higher that follow HTTP two, someday,
44:05 if that happens, I suspect it'll push people quickly. Like, for example, they recently started ranking SSL encrypted sites higher than non encrypted ones, mobile friendly ones, for mobile searches higher and so on.
44:17 Well, they certainly rank are they valid, your page load time. And to the extent that making good use of HTTP two can help your page load time, I think you'll see that reflected whether they make an explicit HTTP to differentiate or not. Yeah, so up there.
44:36 So one of the things that you did is you said, Well, I, this is how I kind of got to this conversation is like, Django and the whiskey servers in general are not super for this long term connection story. So you brought up tornado. And so tell us about tornado. Like, what's the use case here?
44:56 Well, as I said before, I really liked tornado. came from friendfeed. before they're acquired by Facebook, and it's, it's been kept going ever since it's a, it's its own sort of event loop base network IO for concurrent, you know, highly concurrent web applications and has a small web framework that comes with it, where you're basically talking directly with the socket a little bit different than how you write a whiskey application, you're a lot closer to the raw TCP connection. And so part of it was sort of lone tornado does great things in supporting Python three for a while. And again, that really goes with sort of our message of pushing in Python three forward, what we wanted to capture was a tornado is awesome. You want to use tornado, you already know Django, have you make them play nicely together? And I think that's the most important aspect of those chapters is let tornado do what tornado does well, and let Jenga do what Django does well, and learn how to make them work together.
46:10 Right? Absolutely. So you can focus the WebSocket processing on the small tornado site, and then do the rest, basically, through Django, right. And the trick is, how to make them talk together, because it's pretty easy to set up a WebSocket system. So you can say, Well, here's all the listeners on this channel, I made some change, broadcasts out a message to everybody this thing change. And maybe it's not a message but a JSON document that like tells backbone to update the UI this way or that, right. But then they could also go to the website and like, add a new card to the Kanban. board. And you want them to see that everybody else and you want to do that through WebSockets. So tell us quickly, sort of what's what's the connection there? How do you pull that off?
46:56 Since the the choice that we made was to expose the Django server already had a REST API, that's what the previous chapters were all about. That's where the browser's primarily talking to adding adding new items to the board and moving them around. And then along with the WebSocket, the tornado server has its own sort of small, I don't really want to call it rest. Look, it's not very restful Chrome app, but another HTTP endpoint where you can accept changes that come over. So essentially, the browser makes a request to the REST API on the Django server, and that change gets propagated over by making another HTTP request over to the tornado's server. And then that gets broadcast out to any of the connected WebSocket clients that might be interested in. Okay, cool. So the the flow goes something like the JavaScript client talks to Django via rest, then the Django server tells the tornado server via an API that this thing has happened. And then tornado pushes that back
48:03 down to everybody, except for maybe the person who made the change via WebSockets. Right?
48:09 Yeah, it's kind of sir.
48:12 That's pretty awesome. One thing that you mentioned that I hadn't played with or really thought about is Redis. Message Broker, because so far, the stuff we talked about would work well, if like, tornado the process is managing all the connections. But what if you have like scale out to we buy 10, tornado, web front ends or WebSocket? Friends? What do you call it? How did you how did you get that to work? So maybe tell you about how you were working that up?
48:42 This is one of the things that I kind of love and hate about this section, I think I would probably rewrite it like chose read is because it's simple. And it certainly gets the job done that I would have really loved to use rabid if I didn't feel like it would have added a ton of complexity here to sort of talk about and up and all those things. But we are threat is basically Redis is the inter process communication protocol between the tornado consists so Jenga doesn't know anything about Redis and doesn't publish to indirectly Redis is just the intermediary between if you're running multiple tornado processes, and it's got great pumps of support, and then run is broadcast only. But that works for our example. So it's definitely a serving, familiar, pragmatic approach to doing you know, simple broadcast example.
49:45 It seems like a good choice. I mean, you don't want to spend a whole nother chapter on like message brokers.
49:48 And yeah, yeah, I mean, we wanted to make it so that it can stay on the single process because it's a big pet peeve of mine. When to sort of see the sort of toy example, as they were kind of using it is like, well, it's easy because it doesn't scale like beyond a single process. And it has no fault tolerance or high availability possibilities at all. And it's really disingenuous to say, look how easy to easy when you cut out all those things that people care about. In applications. Yeah, that's
50:25 a good point. And for WebSockets, it's more important to have some kind of like fault tolerance, right? Because people are constantly connected. It's not just an instantaneous request, and they have their page. They're like, connected and waiting.
50:38 But yeah, Redis is easy to get up, up and running with people originally rented for caching as well. And it's nice to kind of have technologies that can do a little, you know, are pushing the boundaries of scale on it, you can make use of Redis in other ways,
50:58 once you have it. It's really interesting. I didn't think about that use. That's great. So I think that's about all the time we had to talk about the book. But I found it really interesting. I like the take on the lightweight aspect. I like to take chili, like you said like, but you can do that with Django. So here's I'll show you. Nice work. Thank you. Yeah, you bet. So you said at the beginning and how you got started, you know, okay, let's write a book. Okay, advice you have for others who are thinking about writing a technical book,
51:26 one of the mistakes, I feel like I made was assuming like, Oh, yeah, I haven't read a chapter like that quick enough. I could do that, like so quickly. And once a week, it's gonna be wild, like, well, he's
51:38 putting, like, a month we're done.
51:39 I think,
51:41 I think we had gotten like, maybe Mark was like two chapters done. And we were like, Oh, we've got this like this, no big deal. And that was a mistake. So might be to write 50% of the book before you even pitch it. Yet it I mean, it, like, just write it, like get it at least get a really healthy outline down because
52:08 you think you know, but you don't? Yeah,
52:12 when it comes down to editing, especially when it comes to technical book, because you're not just writing content about in teaching content. And, Michael, I think you understand this for like what you do every day, you know, it's not just about that. It's also about refinement, and testing, and verifying and seeing how can I make this better? It's like this mega mega project. So
52:37 yeah, for sure, in a few, right, try to make a jump that's too big. You can lose people, right? And so you got to make sure that you can continually carry them along. And it's a big challenge.
52:47 Or if you're too academic and your use of Python, which I love that mark brought that up, because we weren't sure if that was a bad thing. They give us like one star for that we're like, I'm actually pretty proud of that.
53:00 I think that's actually kind
53:01 of cool. threw me in with Stanford, MIT. I'll take that. That's awesome. Two questions, I always ask my guests on the way out the door. So Julia, go the first, what is your favorite pie pie package we have over 90,000 now, and I'm sure there's some of us that are great.
53:20 Well, I really enjoy keeping my things neat and tidy, especially when it comes to using Git. And while branches are cheap, I still like removing them. I'm not using them anymore. So I really like this little package called Git sweet, which verifies what's been merged in and what hasn't been cleaned them up. Oh, nice. So
53:36 if you do like a pull request, and that request is accepted, the Git sweep will automatically delete the branch or something like that.
53:43 Yeah, yeah. So you can like so you can just keep everything nice and
53:47 tidy. Hence the name gets.
53:50 Okay. That's awesome. And then of course, pi ladies, which has very dear place in my
53:55 nice what is the PI ladies package I know a pilot is the organization is
53:59 so it's actually an a kit. So let's say you want to start a pilot is in your local area, then you can just put themselves highlighters. And then you can get a whole information package of how you can get started. And I believe that the package is really nice sinks built up a sink. So like, I don't know if it's based off of read the Docs or just straight up sinks. I can't remember. But yeah, it's
54:22 yes.
54:23 Nice little thing. Lynn root made it because she's amazing. Yeah, that's
54:27 awesome. Yeah, I had her on the show. She's great. Mark, how
54:29 about you and my favorite fact is Django. Obviously that is my livelihood, and thankful to have found it. And beyond that, I mean, I like a lot of sort of linting tools, like grateful for flake eight, and the suite of tools around pi code style and pi flakes. I make a lot of typos. And so it helps me catch when I misspelled a variable in one place to say hey, You're trying to use a variable that's never been used, or a variable that you thought you were using intervene, you installed it wrong. helps me find dead code or code that is important and not use. So I really always install like a
55:17 Yeah, that's a great, that's great advice. All right. So the other question I always ask is, when you write Python code, what energy you use Julia,
55:26 I don't have really a favorite. I think it's whatever I need to use at the time, depending on what space I'm in. Because I've used sublime. But if you'll see used Adam, and he's them, sometimes we just kind of like, don't want to leave command line. But it's not like I don't, I just don't really have a favorite, whatever, whatever works at the time. All right.
55:45 Be flexible, awesome, Mark.
55:48 As pretentious as those are like them. I switched over years ago. And it's been really nice. It really helps me focus to just sort of see one file open at a time and have to be very deliberate about moving out of that file into another one. And whereas I found myself when I switched from sublime, and I just found myself having 1000 files open in a billion tabs and clicking around everywhere to try to find where I was going. And then this really helped me focus on one task at a time. Oh, yeah, that's
56:25 a really cool advantage. All right, guys, final call to action. What do people do to get started your book or take advantage of this whole idea that you're promoting is lightweight Jenga?
56:35 Oh, wait, they haven't checked out the book. It's available for purchase on Riley's website. You can get ebook or beautiful entry version with Hummingbird from the front.
56:46 So be sure to put the link in the show notes so people can check it out.
56:49 We have our code examples up on GitHub, which you can see without purchasing the book, though they won't have a lot of context around them. Additionally, I recorded a webcast with O'Reilly about intermediate topics in Django. So if you sort of fit that audience of, you know, I've done a little bit of Django and I'm not sure where to go beyond the holes sort of tutorial. You can check that out. I cover using Django along with celery for background task processing, and I talked about using flake eight to keep your finger Cool. All right. Awesome. Julia, Mark, thank
57:30 you for being on the show. This is really interesting take on Django and I enjoy talking about with you. Great talking.
57:36 Thank you for having me. This has
57:39 been another episode of talk Python to me. Today's guests have been Julie element and Mark Levin. And this episode has been sponsored by gocd and pi up thank you both for supporting the show. Go CD is the on premise open source Continuous Delivery server will improve your deployment workflow but keep your code and builds in house. Check out go CD at talkpython.fm/g OCD and take control over your process. Are there bugs or vulnerabilities hiding in your apps dependencies or even in their dependencies? Stop guessing and start getting notified by registering your GitHub repo with pi up.io? Are you or a colleague trying to learn Python? Have you tried books and videos that just left you bored by covering topics point by point? Well check out my online course Python jumpstart by building 10 apps at talkpython.fm/course to experience a more engaging way to learn Python. And if you're looking for something a little more advanced, try my write pythonic code course at talk Python FM slash pythonic. You can find the links from this episode at talk Python dot f m slash 88. That's right, I've added a new short link. So anytime you want to get to a particular episode, it's always talkpython.fm/ show number. There's all sorts of cool stuff on the show pages so be sure to check them out. 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, Google Play feed at /play in direct RSS feed at /rss on talk python.fm. Our theme music is developers developers, developers by Cory Smith Goes by some mix. Corey just recently started selling his tracks on iTunes. So I recommend you check it out at talkpython.fm/music. You can browse his tracks he has for sale on iTunes and listen to the full length version of the theme song. This is your host Michael Kennedy. Thanks so much for listening. I really appreciate it. Let's mix.
59:33 Let's get out of here. Dealing with my boys
59:38 having been sleeping I've been using lots of rest