Aymeric is a longtime Django contributor and member of the Django Technical Board. We discuss his background with Django, contributions to the codebase and docs, multiple open-source projects, and more.
Carlton Gibson 0:06
Hi, welcome to another episode of Django Chat, a weekly podcasts on the Django web framework. I'm Carlton Gibson joined by Will Vincent. Hello Will!
Will Vincent 0:13
Hi, Carlton.
Carlton Gibson 0:14
Hello. And today we've got Aymeric Augustin with us who's longtime Django, contributor member of the Django technical board and more Hello, I'm Rick, how are you? Hello, folks, I'm fine. Fine. Thank you for coming on so much.
Aymeric Augustin 0:25
It's pleasure to be on the podcast.
Carlton Gibson 0:27
So, right. Okay, well, I'm just going to a few smart mildly for mine, because you're, you know, when I've got into Django, you want to one of the big sort of people that you're one of the people who were contributing, then you're still around now and it's just like, Wow, so can you tell us about how you got into Django and your his, you know, how did you find the project and, you know, kind of plumbing your backstory there?
Aymeric Augustin 0:49
Well, I think it's mostly a happy accident.
So it goes back to 2010 I think, and at this point, I was working in a company Whose favorite framework was rails, which is a good framework, by the way, and then one of my colleagues one, one day tells me about this from he founds a tool, Django and Python and so while I use a bit of Python earlier internships, but I didn't know much about the language. And and so guys, you have me lynnie is really enthusiastic about a Dingo. And so I check it out. And I'm not sure exactly what what happens next probably I use it for a personal project or something. And then I stumbled on bagger and I discovered a bug tracker, and I thought triaging bugs, and so people have weird hobbies, some people do crosswords and and I do a lot of triage. And eventually I started doing a lot about the dark corners of Django where no one ever goes, except when you're finding a Bergman's or framework or or trying to figure out if something is actually a bagger. And I started knowing a lot about Django. And at one point in insulin elevens as a new project where I get to choose a stack, and so I decided, Okay, let's do a real thing with Django this time, everything Django. And so we become a fairly heavy users of framework. So that was for billing to LIBOR, which was a car sharing service in Paris. And so we're we're invoicing car rentals. And so we're invoicing by the minute because it's a service thing. You You take your car, you drop it back, and so we need accurate billing. And since since we're good engineers, we will start thinking what happens when, during the daylight savings time change. Are we going to invoice minutes minutes, 20 minutes if someone takes the car at the attitude 50 and returned it at 210 and that Since that's how I discovered that Django doesn't have support for a where they timezone, so when you publish it on the blog and Neighbors tell them to sign away, you're doing newspaper, which is where you're what Django was built for, it's fine. But when you when you you're doing enterprises stuff, it can be a bit limited. And so that's how I started writing a proposal to support a where they time to date times with timezone information in Django. And eventually, is this lead up to me joining the team. So at the time, one of the criteria for joining the Django core team was you must have written a major patch. And so I had the patch almost written and as a team lead me committed. So yes, that's how I, I become a contributor.
Carlton Gibson 3:52
Well, that's fantastic. Let's like Wow.
Will Vincent 3:57
Well, that was I think it's 1.4 was When time zones was added in sounder
Aymeric Augustin 4:03
and that,
Will Vincent 4:04
and I think that was also that was the first gap LTS first long term, support release.
Aymeric Augustin 4:09
1.4 was definitely a big release. As any 1.5. We were starting, we started working on Python three 1.6 was a party about making Python three work correctly. And sensor is the next big one, which was harder to to get to was 1.7 since it was the new migrations framework, and also I broke a lot of stuff with uploading, which I still believe to be a good thing in the grand scheme have a Django app as a framework, but it was a some time because of some upgrade pain.
Carlton Gibson 4:42
Yeah. And then you were responsible for templates as well.
Aymeric Augustin 4:47
So that's that's what I did in 1.8. If memory serves as a pluggable template engines, this one was a problem less significant because there were So 30 applications that made it possible to use Jinja two in Django, which was one of the primary requirements there. But having it built into the framework was good. And sweet was an opportunity to clean up some parts of the template engine that still relies a bit too heavily on global status. And so now it's a bit more library like, Yeah,
Will Vincent 5:21
can you talk about so who was who were the active Jango contributors back then? Because I feel like a lot of that knowledge is locked away in a small number of people's brains. Like I don't know exactly who that was. I mean, I have a vague sense Carlton came, you know, before me, but after you, do you recall who you know, who was there at that time and you know, 2011 12 Okay,
Aymeric Augustin 5:44
I'm definitely going to forget some people. So this is a tricky
one, okay. Very active contributor at the time was a Yanis later, and yes, it just does. So well actually became a core developer a couple years before I did. He contributed to countless libraries and also a lot to Django core. And then at the time, we didn't have fellows yet. This came later. We already had a team of maybe 20 or 30 committers. And so it was a project was a was still driven, let's say by the, the second team. I mean, that was a very original team, which was adrene. Jacob was the creators of the framework. Then shortly after came Malcolm and Russell was still around
and
Carlton Gibson 6:47
answers.
Aymeric Augustin 6:49
Another couple people I think, but there were less active when I joined us, so I didn't need them as much as I did these original four and Then, as the team grew to maybe 20, or 25, and at this time, people were still writing and creating their own code, which is something we stopped doing now. Everything goes, it goes through the fellow, etc. So, back then, someone had written a patch, I proceeded to track YouTube's a batch, you've tweaked it a bit, you've committed data to SDN, of course. So yes, it was a bit different
Carlton Gibson 7:25
as what I like about the track, so something comes up every so often people like why don't we move to GitHub issues because GitHub is more user friendly, or more, not user friendly, but it's more accessible to new contributors. But like, the track has this amazing history. So like, all the old subversion commits are mapped and you just click on them and they map back and they go, they end up opening up in GitHub with with like, this was the patch that was done 13 years ago by you know, so and so. I you know, I like that whole the history is still maintained?
Aymeric Augustin 8:01
Yes, we we've kept a lot of history in tracking it must go nearly 14 million now I think
Carlton Gibson 8:08
something like
Aymeric Augustin 8:10
Allah, Allah when when talking about track versus GitHub issues. I always feel a build a bit old school.
While I'm a Django core dinosaur, I am. Stay off my little bit. Yeah, exactly. And because things were that way once doesn't mean that the only way to do it, and one thing we always said we were very attached to is anyone being able to try it back. And so for a very long time in GitHub, only contributors who had commit access could tag issues could close issues. Perhaps this is a bit theoretical because in fact, most of the trade is done by Just a few people, and there must have been fellows. And my ish. I'm so sorry, I'm not sure these arguments hold all that well, and also get up introduced as this feature to anonymous tree edge, or at least to make it much more open a few months ago, and I haven't checked it out. So now the other things to consider if we wanted to move to GitHub issues is first, how do we preserve the history? I've come across a lot of projects. We've imported the bug tracker to GitHub issues. And often some information is kept but a lot is lost. Many links are broken. And I think these two interact is valuable. Very often I have valuable information that dates back for two to five or 10 years, because we're very conscious about writing why we do things in ticket discussions, and the other is more on the open source purist thing. GitHub is a closed source run by a corporation, probably as a way to export the data, but it looks like okay, use the API and scrape with the API. And so what we're comfortable with our self hosted track, where we have a database, and we know where the data is,
Carlton Gibson 10:16
I think the big one there for me is the history because some on a day to day basis, you know, we get three, three new tickets a day on average. And they'll be like, you know, our, there's some issue with model form. And, you know, this has kind of come up before and you're able to search and you're able to thing you say, you know, this was discussed six years ago in this comment, and here's why that that, and that's just amazing. And, you know, so the other project I've worked on a lot is Django rest framework. And that that's always use GitHub. And you you're in the position where you're like, I'm sure this has come up before but I just can't find it. It's just, it's there. If you if you if you happen to find it, but to track it down, it's a much more laborious issue. So, you know, whilst GitHub is I don't know It's exciting or whatever it's I don't I don't think it's as powerful but the Python project to migrating now, right and migrating all their bug tracker to GitHub, so we we get to see what happens to them and how they manage it. And then we can make a decision based on that example.
Aymeric Augustin 11:17
Yeah, and it's good that your while you have a composite point with DRF, which is already a mature product, it's been going for at least eight years, I guess, maybe 10. And what some what it reinforces that we can live with track, even if 12% a bit newcomer unfriendly, and then user argument as well, as a get up close, etc. Yes, it's a pure thing. But some people feel very, very strongly about that. And that's always a factor when you you need consensus to change that sort of thing.
Will Vincent 11:53
Yeah, that's right. What I did want to mention, I don't know if we have in the podcast, just around New contributors that Carlton is been doing a lot of work to apply to Google Summer of docs, which Django has been accepted for. And so there, we're hoping we'll be getting money to have someone to professional technical writer to work on just specifically the contributions section of the Django Doc's, which I think could use some fresh eyes. So that's, I'm excited about that. And I know Carlton's been doing a lot of work on that. So I want to call that out, Carlton, I don't
Carlton Gibson 12:28
know. I've been sort of beating the more contributors drum for you know, last couple of years. And the the feedback that I've had several times is it's just really hard to get going and yeah, iconic. It's the kind of wall of text that contributors got. It's brilliant. It's everything you need to know, but maybe it could be smoother. And but you know, what? We're not technical writers by you know, not as a group. That's not where we focus. So to have if we can have someone come in and give them a fresh look, that's quite exciting for me. I don't know.
Will Vincent 12:58
Yeah. And it's nice to have outside money to help us do that, I guess is part of it too.
Aymeric Augustin 13:03
Yeah, it's really cool that we're getting people dedicated to this.
We're going doing okay. adverting code. I think we've done much better than many other projects and writing documentation. And so if you print to PDF, the Django documentation, I think it was 1500 pages or So yeah, I really like the formation. I think we we raise the bar. Very impressively. Now, it's still explore the content written by experts. I have written some pages inside the content from scratch. And then I read them three years later, and I decided I should really write them differently. But I don't know exactly how to go about it. Because when I understand the, let's say, well, what's important when writing due to condition, I can see good documentation when i when i when i see it, I recognize it.
But I can protect myself. And I
Carlton Gibson 14:04
think that's, that's a fair?
Will Vincent 14:06
Well, we had we had Mikey Ariel on who is a professional technical writer. And I think one thing I've realized, being much, you know, more junior programmer than you all is that there's a big difference between documentation and tutorials. So one of the complaints perhaps if someone new to Django is they'll go into the docks and see documentation that air drops in and says, Okay, well, we have, you know, we have these existing this existing site, and then we're just going to add this little thing. So they show the view portion, they show the model portion, which if you know, Django, well, you can use that but if you're a beginner, intermediate, you need all the rest to get you to that point, you can't just airdrop in. So initially, I was frustrated with the Django Doc's that they didn't do that, but I understand now that a tutorial documentation are very different things. So a lot of what I do is tutorials to kind of ramp someone up so when they get to the docks, they can see Oh, this is relevant, but they have the context for it because docks is is intentionally written for an intermediate advanced level, I would say. And that makes a lot more sense to me, then, you know, I mean, if it was tutorials would be 100,000 pages, the documentation to be fair,
Aymeric Augustin 15:14
there was foresight in the ways that Django transition was was written. In fact, a lot of a great number of things were done right. Very, very early when deal was open sourced. I think I heard Jacob explained once how we bought books and read them about essentially how to do an open source product writer. And one of the things that was done in the condition was to separate tutorials, from how to guides from reference documentation, and then the contributing documentation and then it grew from there. But there's a distinction the origin distinction between tutorial here's how you get started. How to you want to with specific things that he has a whole bunch of explanations on a given topic. And returns is everything you need to know on this part of the framework API, etc. It was there. And if you look at the Index page, it's right there on the right. Now, if you come to the docks through Google, you don't know your landing, you know how to arrange a reference page, and you don't have that oil. So the dock is good. If you get to the homepage and start reading data. Perhaps it's a it's a, it's a bit different if you get air dropped by Google somewhere, and you don't understand the whole logic, especially when they're
Will Vincent 16:37
1500 pages. Yeah, no, fair enough. I mean, it's I still think Django Doc's are the gold standard. I mean, I guess part of it is I'm thinking of this for my own work as a content creator where if I want to do something, if I want to demonstrate Sitemaps For example, I just have a recent tutorial on it. I want to show the sitemap part, but I also need to have all that The preamble. And so what I've just put my own stuff, what I'm going to be doing is having a canonical like a recipes app, where I say, Okay, here's this one place, I will walk you through all the steps. And then all these other things like the search, or this fancy thing, or this specific thing. I'm going to jump from this starting point. So if you need the help, here you go. But I'm not going to just start from start project every time, which is what I've been doing with my stuff, which I think is helpful for people, but is unmaintainable for me to start from absolute scratch every time and I know that Django, you know that there's a number of there's the polls app, there's University examples. When I kind of airdrop in through Google, there's, I suppose it would be nice if there were a couple canonical reference points, but I you know, there's so much information in the docs, it's probably more than could be done from scratch. But anyways, that's the context. I think of that. I think it's nice to be able to say, if you need the help, it's here, but I'm not gonna, you know, I can focus on the point that I want to focus on
Aymeric Augustin 18:00
dachsies is still a living project. And regularly someone goes in and improve the section. Yeah, and it's really like gardening, I mean, things have grown and people are run some pages some content. And then at some point someone needs to rationalize it. And it helps. And sometimes, so we are facing the limits, then what Django call dibs. And so now we no longer have code that removes these. But for a long time, this was the people who created all this, and probably will not do it the best people are writing a tutorial. And now everyone admits that the Django girls tutorial is a better one. And so we freely point people to that tutorial, and the official troll is still there, because we need one. But that's a kind of local optimum. And no one has taken the task of explaining what the better soil for Jango could be. Besides the Django tutorial that already exists, There's no need to do anything about it.
Carlton Gibson 19:01
I mean, it's a massive job to write such a thing as well. I mean, that's not everything has to be in the Django Doc's too. I like that there's there's room for like content creators to common things around the the core documentation but the other just the other day I had someone tweet on tweeted me on Twitter, thanks for the docs are amazing. It's like, Oh, you know, you're welcome. I didn't write them. But yeah.
Aymeric Augustin 19:24
Going back to it for to talk to tutorials for just a comment. I think tutorials are one of the hardest things to write. Because you need to decide that you are not going to talk about a bunch of things that are very important, but not fundamental. And people are going to stick to the fundamentals and take some shortcuts. Hide a few things, just for the sake of getting to the end of the tutorial in a in a decent amount of time. And this is really hard and prone to to bike shedding. So a bit difficult to do in an open source community.
Will Vincent 19:57
Yeah, I'm smiling when you say that because that is the show. versus tell. tension is one that as a content creator, I have all the time. It's it's probably the top feedback I've gotten with my beginner stuff is that I, I just sort of show the steps without explaining everything that happens. But it's because if I explained everything that happened, it wouldn't be for beginners. And so there is a balance there between getting it to work and then understanding everything. And I like to say, you know, hey, everything is magic at some point. And so it's just a question of adding in, okay, this is how this works. This is how that works. I can use it without understanding all of it. Because ultimately, why do people use Jenkins, they want to build the site. So if I can show them, you know, build a blog, and then we can then we can loop in and talk about some of the internals, which I think become interesting once you have spent time with them. But you know, an outsider, I think doesn't particularly care about the internals, they just want an outcome. It only comes with time that they find the internals interesting, and that's yet
Aymeric Augustin 20:58
and those are biases. People who produce the code would like to show off all the smart things that they did in the code.
Will Vincent 21:05
Yeah, sure.
Exactly
Aymeric Augustin 21:08
what needs to be in a tutorial.
Another thing that I find very hard is that when you write documentation, you need to stick a roughly at the right distance from what people already know. If you are too basic, while the content is slow, and and people get bored, and if you you are to fall, it's simply not understandable. And well perhaps if you're doing a lot of writing for for beginners, or intermediate people, you get a better feel about this distance, but I find it really hard. In fact, to judge,
Will Vincent 21:44
you have to make an assumption, I think is what it comes down to. You have to make an assumption about their, their level and then go from there. So a blog for a beginner is different for intermediate it's different for advanced and the hard part is deciding and then sticking to It, especially, you know, for me, as my own knowledge has advanced, I find it. It's not interesting for me to show another very beginner thing. But because I interact everyday with beginners, it kind of keeps me in that mindset where it's interesting and not just monotonous for me. So I'm, I certainly feel, I don't really want to code beginner stuff, because I kind of know that but at the same time, I don't I, I get the perspective of beginners in their frustrations. And I recall my own frustrations. So I yeah, it's a hard thing. And that's why I say with the docs, you have to, to me, I think the docs are at an intermediate level as they should be. It's sort of one of the things actually I want to do in my own online site is mimic what you would do in person were in person, the first thing you would do is kind of say, well, what's your level? Because then I will talk to you at that level. So one thing I've I think I will be doing is having a, okay, are you a beginner or intermediate or advanced, like Tell me and then I will point you to tutorials that go up from that. jumping off place, because without that it's Yeah, it's, it's hard to know where someone's at. And it's hard to write those things. I think it's harder to write the beginner things, actually than the advanced things because you can't assume anything. I think it's harder actually to write the beginner ones. Let's say if you have the knowledge of C, it's
Aymeric Augustin 23:17
very easy to skip an implicit piece of information. And without that information
as the gaps the
the storage
Carlton Gibson 23:29
example, that comes to mind narrows imports, so quite a lot of times in the documentation, we'll get a pull request sink, we please add the import for you know, this particular class that we've shown you is because people come to the docks and say, Well, where do I get this? Where is this class? It's, it's just not shown. And then as soon as you have the input to the code example, it's become so much more useful.
Aymeric Augustin 23:49
And there are a couple tricks for integrating with the Django Doc's. And I know them and I feel bad about them. So one is that it's usually bad. to type a site column, ducks dingleberry.com, your query in Google then use the built in search engine. Because Google, just better assertion genes. And the other one is when you, you hover over the name of a function in APA documentation, you get a link. And in that link, there is an anchor. And the anchor contains a full import path. And so this is how, you know, Britain that completely in places and people I've explained tracks that were doing this, usually when asked making the important places, explicit, I mean, but yeah, it's bad that we're relying on this.
Carlton Gibson 24:43
I mean, there's probably some Sphynx plugin that we could find that would fix all of that for us but we're yet to find it. One thing I wanted to talk to you about Eric was while I've got you on is the Django static static files story because he's you know, back in the day very much he you know, static rendered HTML and You know, I'm a big fan of that still in that it's got, you know, I like to render templates and serve up HTML. But a lot of times we serve up API data and then we there's a single page application. And we merge it with react or, you know, view or some whatever rich client. And something that comes up every year, I think is is what's Django static file storage, or can we improve it? And I know you've got thoughts on this. I did want to talk while we had to ask you to comment on that, if you can,
Aymeric Augustin 25:30
yes. I think static files is a vastly underappreciated part of Django. And Yanis. has been doing an amazing job there. To bring it to a level where it's very, very useful without becoming a full acid pipelines that would have no place in Django. I mean, on some points if you want to get back up.
So if we win the story, when we're originally
you deploy Django on Apache with mud Python is going to store your files. css, demonstrate user Upload Media. Well, I mean, you probably be Well, I mean, at first it was a newspaper. So it was editors upload images that would get served with the with the website. And so Apache says it says all this. So one of the first distinctions of crops apps is that user provided. Media is not the same as JavaScript and CSS. And so this is when Jango starts separating static files from media files. This is not completely clean yet. When you define a form, you just see the form a media API, which is actually static files. And while we could clean this up,
it's not a very big deal, but it's unclean. So then
As the world progresses, from just stacking bunch of jQuery, jQuery plugins and CSS files, as things less like a sass appear, so then best practices for managing scripts and styles appear, and essentially practice about cache invalidation. So when was the most reliable way to invalidate a resource on the web is not to mess with HTTP headers, because there's always a browser that will get it wrong, it just to change the name of the file, and cache everything forever. So modern static files that does this well, it takes a bunch of CSS and JavaScript spread out your Django application hashes the content of the file as the hash of the file name, and then you can serve everything cached forever. And then if you use white noise You can do everything inside your wizzy application with good performance. And you no longer need to care about serving static files separately from the website itself. So this is really good. And it's also compatible with modern JavaScript practices. Because if you, let's say you've built a front end with something like react, or view or whatever, Ember, you bundle it with a bundler, such as web pack, this produces a bunch of JavaScript files. You can tell Django to use as a directory was this type end up, you put it in static files years. And then this is how you can bridge between Django and a front end framework when you're still building something that looks like a traditional website, where everything is served from from the same URL. And so if you want to optimize this, you can, you can do it using like avoiding double hashing. If web pack hash is once and Django hashes a second time, you can also leave with it because honestly, it's not a big deal. But very often, people get confused about how do i do modern JavaScript front end with Django? And the answer is just do your front end, and then gives a fight to Django, and lets the device handle the rest. And it can result in a fairly simple deployment pipeline. So now, if you want to know all the gory details, there's a few past my blog where I explained how to do this. And I call it the hybrid app model, because it's hybrid between traditional Django plus templates, server side stuff, and modern browser side application today.
Will Vincent 29:56
Yeah, we're definitely gonna link to those. I think it's three posts that you wrote out. I found those to be excellent. I mean, obviously excellent, but illuminated for me when I was going through this, I think two years ago. And because it is a common thing that comes up and I recall seeing Jacob Kaplan moss give a talk on static files at pi con 2019, where he sort of spent a lot of time to think, is there a much easier story than what we have? I guess just, you know, for coupling static files? And his answer was not so much keep it simple,
Aymeric Augustin 30:27
was another fairly simple story, which is as a single page application architecture, when you deploy on one side, static HTML index that is just there for booting some JavaScript as it builds the entire application. On the other side, you deploy an API, and the only thing you need to get right is cross origin requests. Because the aka will run a different domain from where the HTML is served. The and usually authentication. So this is also something when I was doing consulting, I've repeatedly seen people tying themselves into knots. With this, bringing a JW t into the mix, which is honestly not necessary for this proposal. just added some TK tweak with cookies on the domain of the API, it will work just fine. And set up your cross origin request headers properly. And and in one of these blog posts you just mentioned as a whole story. But again, if you think you need DWT to do this, you're probably opening yourself to security risks, and you shouldn't
Will Vincent 31:41
we just had david Sanders on who wrote the Django simple JW t package, which is now I think, the default JDBC package and just for those who want further discussion of JW Ts, I wanted to ask you about Django sesame, which is one of your projects that I find really interesting. So this As magic links where URL one click login, can you talk about the why you wrote this, and how it might be used because I'm probably gonna be using it for something very soon. So when I found this, I forget, he showed it to me. I was like,
I was me. I was conscious. Of course, it was Carl
Carlton, I really cool
Aymeric Augustin 32:18
backstory about this one, and also some hot news. And so, and like any self respecting geek, I'm not going to give my photos to proprietary custom, because I care about my photos. And I still want to have them around in 50 years. So I'm storing them in JPEG in a file system that they can sync anywhere. So they used to be synced on my laptop on a server. I own that on s3. And now I decided that the three is fairly reliable, and so they're just on my laptop and on s3. So anyway, I still like watching my photos on the web. And s3 is not a very convenient way to do that. And so I built a small application that's called Django gallery or mix gallery Because it's just my own to have an index of the photos of the database and a few views, to show them by albums, very basic stuff, and nowhere near as good as anything you'd get on any cloud based service. But it works with my directory of photos on s3. And then I got children, and I wanted to show the photos to my family. And so then the way to access the photos, but I didn't want to put them on the whole internet, obviously. And so I need to give access to my personal website. And at some point, giving your parents a login and password to Ward's the photos on your website starts feeling a bit weird. And so I decided I was just going to send something they can click and get integrated with Django did contribute Earth and get access to the photos. And since I was a super elaborate permission system in MCs galleries, it's so complicated that I never intended fully but Yet another story. And so Django says me, which used to be called Django URLs, but there was a note of Django URLs. So it to change the name
was really do this. It's a nice use case. But there are many,
many other and much more common use cases for using tokens. And so then I generalize the system to support tokens that could expire, which didn't matter in the original use case, to support one time tokens, that sort of thing.
And ends approach as a little bit of success. And now,
Will Vincent 34:39
I love that backstory
Aymeric Augustin 34:40
for the hot news. Um, recently, a contributor suggested a better designer for the tokens. So it's a it's a fairly theoretical argument as since I want tokens to be invalidated and password change. This is a decent way to invalidate that token. I'm hashing the hash of the password into talking. So it's supposed to be secure. But when you take the hashed password and Java database and put it into something that would be in URLs in emails in web server logs, virtually everywhere, it is a bit shaky. Even if you think your crypto briefly cryptographically secure. And so this guy said, Why don't you take just the hash pot, and not as a salt and the algorithm and everything else, as it's more secure, because you have entropy from the salt in addition to intuitional password. So pretty good idea. And, but this requires changing the token format, and then supporting to token format, etc, etc. So I've been working on this for the last few weeks, and I'm going to put out a new release, which will have much shorter tokens, which will be much more relevant in URLs as this matters to me And the trick is that instead of putting an identifier of the users the primary key, a hash of the email and last login date, and then hashing the whole thing with Django code signing, which produces fairly tokens, and doing a single hash and putting just a prior primary key and doing a single hash that encodes all the rest of the function t I need, and so the token can be shorter.
Will Vincent 36:25
Awesome.
Aymeric Augustin 36:26
Yeah. So so it's really another thing to spend a bunch of I was trying just for the tokens for something that makes absolutely no difference in practice. Now,
Will Vincent 36:36
there will be better. I was just thinking, as you were saying it, you know, there's a saying that every developer, when they want to write a blog, they end up writing a static site generator from scratch. And I feel like every developer who has kids wants to have photos that aren't on Instagram or somewhere because I've, I've built a prototype of this. I think it's maybe it's like the next level for a developer. You have kids and you're like, I don't want to put my pictures up on The wide web and then, like I built a simple Django site and I sharing logins with parents, and it's too much. And I love that you play that out further. And that's the backstory for this
Aymeric Augustin 37:11
package. We don't judge people who have children and decides they need to build shells in their house or something. So we shouldn't judge developers of things that need to write their own for the website.
Will Vincent 37:24
So we were coming a little bit up on time, I have a note here to ask you about Django debug toolbar.
Carlton Gibson 37:29
Yeah, cuz you were you were you wrote that or you were maintaining it for a while, or did you? Like what's the backstory like so it's one of the major pieces of infrastructure,
Aymeric Augustin 37:37
I still think I picked it up at a time where it was in need of some maintenance. I modernized it a beta, probably deprecated some some stuff that that sounds difficult to maintain. So I don't remember as it started, because I had made changes in Django that would break the toolbar. It's possible that started when I did the template stuff, and uncensor toolbar, which uses a lot of Intel Django API's needed to be a daily to counter writer, then I didn't do it for for very long because it's fairly stable. And I think other people picked up the flag. So it was a temporary thing.
Carlton Gibson 38:19
Yes, it's it's part, it's part of the jazz band thing now.
Will Vincent 38:23
The Jazz Band group, you have the the Python WebSockets that repo, what's the backstory, and all that,
Aymeric Augustin 38:31
um, the backstory is that I was working at a company where we had a project to deploy batteries, so like big batteries to power homes or castle, a little thing in Africa, and we'd need to manage them. And we wanted a protocol that was fairly easy to use from Let's say modern software. So like sending raw TCP packets, or UDP packets felt a bit low level. And we saw that WebSockets would be convenient to manage centrally, and could be deployed in any small Linux board that could be next to the batteries and connected to the battery management system and can be used for for supervision. And so when I started this actually I was I was about to leave the company. So it was one of the last choices I made. And I started building websites for this proposal. Also, because a sink IO was brand new, so it was still cheap at the time. And I wanted to learn it. And so WebSockets was a way to learn a sink IO. And so since the name was available on pi pi, I think it was a good time to grab it.
Carlton Gibson 39:56
Name squatting, I have this name. I need a library
Aymeric Augustin 40:00
So that was a bit ballsy. But I think WebSockets is a pretty good library for doing WebSockets in Python. I think it is very correct. Perhaps not with super convenient, but at least he doesn't do weird stuff. It's also very robust. For instance, at some point, the bison community discovered that you had to handle back pressure in us in case you didn't want your buffers to grow forever, and nothing else nice, I think growth over the past explain all this. And it turns out that WebSockets was the only libraries that did this well, so included correction in the article. So that was my moment of pride was WebSocket I got at least one thing right with a sink IO. So anyway, so WebSocket grew with async IO, he has suffered a bit from the churner in API's into async IO as I think you have matured and now while he does one thing, well, you a basis for building servers or clients in Python, and I've been working on and off since one year to move it to psycho Moodle. So soya was very fashionable two or three years ago, I don't like the long term downtrend. While working on this, I have discovered that if you want to do so you have a core part of the protocol that implements everything except reading and writing bytes and you do it on both end, you end up re implementing a lot of things inside. For instance, you need something like a stream reader bytes get written to this, and then you can ask for read end bytes or read and at the end of line, and we'll use async IO sure you are coupled to the IO, but at least asking can give you a stream reader for free. Then you start thinking about the brighter and so you start reasoning about how you are going to Write the bait to network eventually. And so the more I've been working with saw you, and the more doubts I've had about if it was a good thing. And so I have a brand that is nowhere. So perhaps that would be a saw your version of WebSockets in a few years, perhaps not in a
Carlton Gibson 42:20
bit. It's a good learning exercise either way. No, it is.
Aymeric Augustin 42:24
The actual reason for doing that is that Tom Christie was working on HTTP x. And there was discussions about having WebSocket support is there. So it could have been done with WebSocket as the core saw your thing. So there is Sanic, which is depending on WebSockets. But the integration is a bit shaky, because I never designed WebSocket for this for being integrated into another server. So it would be much cleaner if I did this. So now it's really a matter of whether I find time and interest to go forward with this. Yeah.
Carlton Gibson 43:00
Okay, interesting. So the one thing I wanted to do other project goals which I like a lot, it's called dat Jango sequences which enables you to, from potentially multiple requests, guarantee that you're going to get an ordered sequence identifies which you might use. The reason I use it is for invoice generation, if you need sequential invoice numbers, perhaps tell us a little bit about that.
Aymeric Augustin 43:27
That's why it exists. So you remember I talked earlier about auto leaves the car sharing service, and then one day, our accounting which were written in the system, gets an audit and auditors come back saying it's one of the best homegrown accounting that I've ever seen because your level is, I don't know it was zero point something percent, but good enough. But we have gaps in the invoices and this is bad and because what no one told us you were not allowed to have gaps in sequence of invoices. And we have done because of connection rollbacks. Because we were we, we discovered that when you have a technical rollback in Postgres, it can swallow a number in the sequence of primary keys. So Jango sequences. Wow. First off, I mean, it's the sort of thing everyone knows one day. I mean, you you don't know that the invoice numbers have to be sequential. But someone tells you you messed up.
Will Vincent 44:23
Yeah. So I think we're pretty much out of time. Is there anything any other projects you're working on or work things you want to mention before we go?
Aymeric Augustin 44:32
Um, well, right now I'm trying to give a some maintenance to most of my passion projects. And well, in fact, there's a good chance that I write open source in other technologies, as I'm about to take a new job, which is very good, except there's no danger in there. It's a razor Ember and go all of which are good technology. They think that Well, probably I'll be writing more Ruby and, and go and just keep going forwards and bison probably a bit of Python for data for data anyway, since it's going strong there, but well, we will see.
Will Vincent 45:11
Well, I suspect you'll find your way back to Django one way or another professionally and the lessons you've learned from those communities will will cycle back so
Aymeric Augustin 45:20
sure. Well, I'm also looking forward to appreciating rails more. I've wrote some Ruby on Rails a very long ago, I think 12 years ago, roughly. And back then, I decided that Django was probably better. Now with a decade of experience, I would probably have a different judgment for the more measured and raised world gets right and in the Django world we've been missing. And so I'm really looking forward to well, seeing what I can do bring across from one ecosystem. The other
Carlton Gibson 46:00
thing I really like about Rails is the controller guess it just gets you like, it's like generic views, but it gets you there that much quicker. And, you know, there's a little bit less. It's like you're out the gate slightly faster with rails, that's what I really like about it. And then, you know, as you get deeper in, it's the, you know, you can do whatever in either, but I think that's something that we could try to emulate more in Django is, is that, you know, I've got, I've got a model, that's all fine. And then how do I get, you know, the form view in place really quickly, and they do things like the AJAX forms, which are, you know, nice, and then the turbo links is built in and you know, maybe we don't have to copy any of that, but it's, that's what I like when I'm using it, I think, yeah, this is good.
Aymeric Augustin 46:45
Yes, there are some differences in things raised those and we wouldn't do them in Django. It's it's also nice if each framework has its preferences that cater to the taste of different people. Generally, Python and Django has been much more boring, which I enjoy a lot. But again, 10 years have passed. So perhaps raisins become boring as well. That's really good.
Carlton Gibson 47:10
Yeah, if you if you read Hacker News, it's definitely boring like Django and rails. They're always in the, you know,
Will Vincent 47:15
people are rediscovering they're like, Yeah, I thought this wasn't anything. But Wow, compared to this JavaScript thing. Django has rails pretty good.
Carlton Gibson 47:22
That sounds like how can you say?
Will Vincent 47:24
Yeah, yeah. Well, thank you so much for taking the time to come on. I mean, from the beginning. You've been one of the people really wanted to have on and talk to you. I've never, I've never spoken to you before. But I know, you know, your reputation is so huge in the community. So thank you for thank you for doing that. And thank you for coming on to talk about it.
Aymeric Augustin 47:41
Well, thank you for having me on the podcast. Talk to you soon. Yes, super. Thanks.
Will Vincent 47:45
All right. Be well. Bye.