Transcript: Aymeric Augustin

Hi, welcome to another episode of Django Chat, a weekly podcast on the Django web framework.

I'm Carlton Gibson, joined as ever by Will Vincent.

Hello, Will.

Hi, Carlton.

Hello, Will.

And today we've got Emmerich Augustin with us, who's a long-time Django contributor,

member of the Django Technical Board and more.

Hello, Emmerich.

How are you?

Hello, folks.

I'm fine.

Fine.

Thank you for coming on so much.

It's a pleasure to be on the podcast.

So, okay, well, I'm just going to, a few smart, mildly for a moment, because you're, you know, when I've got into Django, you're one of the big sort of people there.

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, you know, how did you find the project and, you know, kind of some of your backstory there?

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 day he tells me about this framework,

he found that it's called Django,

and he was doing Python.

And so, well, I had used a bit of Python earlier in internships,

but I didn't know much about the language.

And so this guy, Jeremy Lenné,

is really enthusiastic about Django.

And so I check it out,

And I'm not sure exactly what happens next.

Probably I use it for a personal project or something.

And then I stumble on a bug, and I discover there's a bug tracker,

and I start triaging bugs.

And so people have weird hobbies.

Some people do crosswords, and I triage.

And then I do a lot of triage.

And eventually I start knowing a lot about the dark corners of Django

where no one ever goes,

except when you're finding a bug in the framework

or trying to figure out if something is actually a bug.

And I start knowing a lot about Django.

And at one point in 2011,

there's 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 fairly heavy users of the framework

so that was for building Autolib

which was a car sharing service in Paris

and so

we're invoicing car

rentals and so we're invoicing

by the minute because it's a service

you take a car, you drop it back

and so

we need accurate billing

and then since we're good engineers

we start

thinking what happens

during the day

like savings time change

Are we going to invoice minutes, minutes, 20 minutes if someone takes the car at 2.50 and returns it at 2.10?

And that's how I discovered that Django doesn't have support for aware date times.

So when you're publishing on the blog, a naive date times are just fine.

When you're doing a newspaper, which is what Django was built for, it's fine.

But when you're doing enterprise stuff,

it can be a bit limited.

And so that's how I started writing a proposal

to support aware date times,

date times with time zone information in Django.

And eventually, this led 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 the team let me commit it.

So yeah, that's how I become a contributor.

Well, that's fantastic.

That's like, wow.

Well, that was, I think it's 1.4 was when time zones was added in.

I'm not completely sure when we began to do LTS.

1.4 was definitely a big release.

Then in 1.5, we started working on Python 3.

1.6 was partly about making Python 3 work correctly.

And then the next big one, which was hard to get to, was 1.7,

since there was a new migration framework.

And also, I broke a lot of stuff with uploading,

which I still believe to be a good thing in the grand scheme of Django as a framework.

But it was sometimes a cause of some upgrade pain.

And then you were responsible for templates as well, weren't you?

So that's what I did in 1.8, if memory serves,

so the pluggable template engines.

This one was probably less significant

because there were third-party applications

that made it possible to use Ginger 2 in Django,

which was one of the primary requirements there.

But having it built into the framework was good,

And also it was an opportunity to clean up some parts of the template engine

that still relied a bit too heavily on global status.

So now it's a bit more library-like.

Yeah, okay.

Can you talk about, so who were the active Django contributors back then?

Because I feel like a lot of that knowledge is locked away

in a small number of people's brains.

I don't know exactly who that was.

I mean, I have a vague sense Carlton came before me, but after you.

Do you recall who, you know, who was there at that time in, you know, 2011, 12?

Okay, I'm definitely going to forget some people.

So this is a tricky question.

One very active contributor at the time was Yanis Leidel, alias Segesdez.

So, well, actually, he became a core developer a couple of years before I did.

He contributed to countless libraries and also a lot to Django Core.

Then at the time, well, we didn't have fellows yet, this came later, we already had a team

of maybe 20 or 30 commies, and so the project was still driven, let's say, by the second

team. I mean, there was a very original team, which was Adrian Jacob, who was a creator

of the framework. Then shortly after came Malcolm and Russell, who is still around.

And another couple of people, I think, but they were less active when I joined. So I

I didn't need them as much as I did these original four.

And then the team grew to maybe 20 or 25.

And at this time, people were still writing

and committing their own code,

which is something we stopped doing now.

Everything goes through the fellows, et cetera.

So back then, someone had written a patch,

uploaded it to track, you took the patch,

you tweaked it a bit, you committed it to SVN, of course.

So, yes, it was a bit different.

That's what I like about the track.

So something that comes up every so often is people are like,

why don't we move to GitHub issues?

Because GitHub's 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 end up opening up in GitHub with, like,

This was the patch that was done 13 years ago by, you know, so-and-so.

You know, I like that whole, the history is still maintained.

Yes, we've kept a lot of history in track.

It must go nearly 14 years now, I think.

Yeah, something like that.

And when talking about track versus GitHub issues,

I always feel a bit old school.

Well, I'm a Django core dinosaur.

Stay away from that.

Get off my lawn.

Yeah, exactly.

And because things were that way once

doesn't mean there's the only way to do it.

One thing we always said we were very attached to

is anyone being able to try HBug.

And so for a very long time in GitHub,

only contributors who had comic access

could tag issues, could close issues.

Perhaps this is a bit theoretical

because in fact, most of the triage

is done by just a few people

and now most of it is done by fellows,

so including yourself, Carlton and Mariusz.

So I'm not sure these arguments hold all that well.

And also GitHub introduced this feature

to allow anonymous triage

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

who imported their bug tracker

to GitHub issues.

And often some information is kept,

but a lot is lost.

Many links are broken.

And I think the history in track is valuable.

Very often I find valuable information

that dates back to five or ten years

because we are very conscious about writing

why we do things in ticket discussions.

And the other is more an open source purist thing.

GitHub is a closed source run by a corporation.

Probably there's a way to export the data,

but it looks like, okay, use the API and scrape with the API.

And somewhat we're comfortable with our self-hosted track where we have the database and we know where the data is.

I think the big one there for me is the history.

Because on a day-to-day basis, we get three new tickets a day on average.

And it'll be like, oh, there's some issue with model form and this has got to have come up before.

And you're able to search and you're able to think.

You're able to say, look, this was discussed six years ago in this comment and here's why 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's always

used github and you you're in the position where you're like oh 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 just i don't think it's as powerful but the python project are migrating

now right they're 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 yeah and and it's

good that you're well you have a comparison point with drf which is already a mature project it's

been going for at least eight years i guess or maybe 10 um and well somewhat it reinforces that

We can live with track even if it's, well, perhaps a bit newcomer unfriendly.

And then the other argument, well, the GitHub closed source, et cetera, yes, it's a purist

thing, but some people feel very, very strongly about that.

And that's always a factor when you need consensus to change that sort of thing.

Yeah, that's right.

Well, I did want to mention, I don't know if we have in the podcast.

just around new contributors

that Carlton has been doing a lot of work

to apply to Google Summer of Docs,

which Django has been accepted for.

And so we're hoping we'll be getting money

to have someone to,

a professional technical writer,

to work on just specifically

the contribution section of the Django docs,

which I think could use some fresh eyes.

So I'm excited about that.

And I know Carlton's been doing a lot of work on that.

So I wanted to call that out, Carlton,

Yeah, no, I'm excited about this. I've been sort of beating the more contributors drum for, you know, last couple of years. And the feedback that I've had several times is it's just really hard to get going. And yeah, it's a kind of wall of text that contributors got. It's brilliant. There's everything you need to know, but maybe it could be smoother.

but you know we're 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 that a fresh look that's quite exciting

for me i don't know yeah and it's nice to have outside money to help us do that i guess it's

part of it too yeah it's really cool that we're getting uh um people dedicated to this uh we're

going doing okay at writing code uh i think we've done much better than many other projects uh at

writing documentation yeah and so if you print to pdf the django documentation i think it runs

1500 pages or so yeah and so there's really a lot of information i think we we raise the bar

very impressively uh now it's still expert documentation written by experts i i have

written some pages in in that documentation 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 uh because while i understand uh the the let's say um well what's important when

writing good documentation i can see good documentation when i when i see it i recognize it

um but i can't write it myself and i'm not the only one i think that's that's a fair well we had

we had mikey ariel on uh who is a professional technical writer and i think one thing i've

realized, being much more junior programmer than you all, is that there's a big difference between

documentation and tutorials. So one of the complaints, perhaps, of someone new to Django

is they'll go into the docs and see a documentation that airdrops in and says, okay, well, we have

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 docs that they didn't do that. But I

understand now that a tutorial and 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 docs, they can see, oh, this is

relevant, but they have the context for it because docs is intentionally written for an intermediate

advanced level, I would say. And that makes a lot more sense to me than, you know, I mean,

If it was tutorials, it would be 100,000 pages, the documentation.

Well, to be fair, there was foresight in the way the Django documentation was written.

In fact, a great number of things were done right very, very early when Django was open sourced.

I think I heard Jacob explain once how he bought books and read them about essentially how to do an open source project right.

And one of the things that was done in the documentation

was to separate tutorials from how-to guides

from reference documentation

and then the contributing documentation.

And then it grew from there.

But the distinction, the original distinction between tutorial,

here's how you get started, how-to,

you want to do specific things,

here's a whole bunch of explanations on a given topic,

And reference is everything you need to know on this part of the framework, the API, etc.

It was there.

And if you look at the index page, it's right there under your eyes.

Now, if you come to the docs through Google, you don't know if you're landing in a how-to or in a reference page.

And you don't know that it's a tutorial.

So the doc is good if you get to the homepage and start reading it.

perhaps it's a it's a it's a bit different if you get airdropped by google somewhere

and you don't understand the whole logic especially when they're 1500 pages yeah no fair enough i mean

it's i still think django docs are the gold standard uh i mean i and 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 the preamble. And so what I've, just with my own stuff, what

I'm going to be doing is having a canonical, like a recipes app where I say, okay, here is 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, 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 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 well the docs is still a living project and regularly someone goes in and improve a section

yeah and it's really like gardening i mean things have grown and people have grown some pages some

content and then at some point someone needs to rationalize it uh and it helps and um sometimes

also we are facing the limits

than what

Django core devs

so now we no longer have core devs, we removed this

but for a long time these were the people who created

all this and perhaps they were not

the best people at 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 tutorial is still there

because we need one

but well, that's a

kind of local optimum

and no one has taken the task of explaining

what a better tutorial for Django could be

besides the Django tutorial that already exists

so there's no need to do anything about it

I mean it's a massive job to write such a thing as well

not everything has to be in the Django docs too

I like that there's room for content creators to come

and add things around the core documentation

but just the other day I had someone tweet at me on Twitter

thanks for the docs, they're amazing

it's like well you know you're welcome i didn't write them but you know you're welcome and perhaps

going back to for tutorials for just a comment uh 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 uh but not fundamental and so you're going to stick to the fundamentals and

take some shortcuts uh hide a few things just for the sake of getting to the end of the tutorial in

in a decent amount of time and this is really hard and prone to bike shedding so

a bit difficult to do in an open source community yeah i'm smiling when you say that because that is

the the show versus tell um 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 Django? They want to build a 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 another bias of the people who wrote the code it's like

they would like to show off all the smart things that they did in the code yeah

Well, it's definitely not what needs to be in a tutorial.

Another thing that I find very hard is that when you write documentation,

you need to stick roughly at the right distance from what people already know.

If you are too basic, well, the documentation is slow and people get bored.

And if you are too far, it's simply not understandable.

And, well, perhaps if you're doing a lot of writing for beginners or intermediate people, you get a better feel about this distance.

But I find it really hard, in fact, to judge.

You have to make an assumption, I think is what it comes down to.

You have to make an assumption about their level and then go from there.

So a blog for a beginner is different for an intermediate, is 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 every day 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 get the perspective of beginners and their frustrations. And I recall

my own frustrations. So I, yeah, it's, 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. Um,

and 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 where in person, the first thing you would do is kind of say, well,

what's your level? Cause then I will talk to you at that level. Uh, so one thing I've,

I think I will be doing is having a, okay, are you a beginner? Are you intermediate? Are you

advanced like tell me and then i will point you to tutorials that go 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 um i think it's harder actually to write the beginner ones

let's say because if you have the knowledge of it's very easy um to skip an implicit piece of

information and without that information uh the gaps the the storage example that comes to mind

there is imports so quite a lot of times in the documentation we'll get a pull request saying can

we please add the import for you know this particular class that we're showing using because

people come to the docs and it's like well where do i get this where is this class it's it's just

not shown and then as soon as you as soon as you add the import to the code example it's become so

much more useful.

There are a couple of tricks for interacting with the Django docs.

And I know them and I feel bad about them.

So one is that it's usually better to type

site colon docs.jangoproject.com

your query in Google than use a built-in search engine

because Google is just better at search engines.

And the other one is when you hover

the name of a function in API 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 uh that's completely implicit uh and and people i've explained in

tracks that we're doing this usually when they asked making the import implicit explicit i mean

uh but yeah it's bad that we're relying on this i mean there's probably some sphinx plug-in that

we could find that would fix all of that for us but we're yet to find it one thing i wanted to

to talk to you about, Emmerich,

was, while I've got you on,

is the Django static file story.

Because these, you know,

back in the day,

very much static rendered HTML,

and, you know,

I'm a big fan of that still,

and 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 there's a single page application,

and we merge it with React,

or, you know, Vue,

or some, whatever, rich client.

And something that comes up

every year i think is is what's django static file story or can we improve it and i know you've got

thoughts on this so i did want to sort of while we had you ask you to comment on that if you can

yes um i think static files is a vastly uh underappreciated part of django uh and janice

has been doing an amazing job there um to bring it to a level where it's very generally useful

without becoming a full asset pipeline

that would have no place in Django.

I mean, at some point, if you want Webpack, use Webpack.

So if we rewind the story,

when, well, originally,

you deploy Django on Apache with ModPython

or ModWhiskey later,

and Apache is going to store your files,

CSS, JavaScript, user-uploaded media.

Well, I mean, user-uploaded, well, I mean, at first it was a newspaper,

so it was editors uploading images that would get served together with a website.

And so Apache says all this.

So one of the first distinctions that crops up

is that user-provided media is not the same as JavaScript and CSS.

And so this is when Django starts separating static files from media files.

This is not completely clean yet.

When you define a form, there's still a form, a media API,

which is actually static files.

And, well, 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 a bunch of jQuery plugins and CSS files,

as things like Sass appear,

So, then, best practices for managing scripts and styles appear,

and essentially practices about cache invalidation.

So, 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's just to change the name of the file and cache everything forever.

So modern static files does this well.

It takes a bunch of CSS and JavaScript,

spread out your Django application,

hashes the content of the file,

adds a hash in the file name,

and then you can serve everything cached forever.

And then if you use white noise,

you can do everything inside your WSIGI 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 Vue or whatever, Ember,

you bundle it with a bundler such as Webpack,

this produces a bunch of JavaScript files

you can tell Django

to use the directory

where these files end up

you put it in static files

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 the same URL

and so if you want to

optimize this

you can do a few things like avoiding

double hashing. If Webpack

hashes once and Django hashes a second time

you can also live with it

because honestly it's not a big deal.

But

very often people get

confused about how do I

do modern

JavaScript frontend with Django

and the answer is just do your

frontend and then give the file to

Django and let static files 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 posts on my blog

where I explain how to do this.

I call it the hybrid app model

because it's hybrid between a traditional Django

plus templates, server-side stuff,

and a modern browser-side application.

Yeah, we're definitely going to link to those.

I think it's three posts that you wrote.

I found those to be excellent.

I mean, obviously excellent,

but Illumina, for me, when I was going through this,

I think, two years ago, because it is a common thing that comes up.

And I recall seeing Jacob Kaplan-Moss give a talk on static files at PyCon 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 for coupling static files?

And his answer was, not so much. Keep it simple.

Well, there's another fairly simple story,

which is the single-page application architecture.

When you deploy on one side a static HTML index

that is just there for booting some JavaScript

that 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 API will run on a different domain

from where the HTML is served,

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 up JWT into the mix,

which is honestly not necessary for this purpose.

Just authenticate with cookies on the domain of the API,

if we were just fine,

and set up your cross-origin request headers properly.

And in one of these blog posts, you just mentioned the whole story.

uh but again if you think you need jwt to do this you're probably opening yourself to security risks

and you shouldn't we just had david sanders on who wrote the jango simple jwt package which is now

i think the default um jwt package and just for those who want further discussion of jwts

i wanted to ask you about jango sesame which is one of your projects that

uh i find really interesting so this is 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 i'm probably gonna be using it

for something very soon so when i found this i forget who showed it to me i was like oh my god

it was me oh it's carlton of course it was carlton of course it was carlton a really cool

backstory about this one uh and also some hot news um so um like any uh self-respecting geek

I'm not going to give my

photos to

a proprietary car system 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 I can

sync anywhere. So they used

to be synced on my laptop, on a server I owned

and on F3 and now I have decided

that F3 is fairly reliable and so

they're just on my laptop and on F3.

So anyway, I still

like watching my photos on the web and F3

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

so very basic stuff

and nowhere near as good 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

a 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 to your parents a login and a password to watch the photos

on your personal website starts feeling a bit weird, and so I decided I was just going

to send something that they can click and be authenticated with django.contrib.auth

and get access to the photos.

And then there's a super elaborate permission system

in MixedGallery that's so complicated

that I never implemented it fully.

But that's yet another story.

So Django, Sesame,

which used to be called Django URL Oath,

but there was another Django URL Oath,

so I had to change the name,

was created to do this.

It's a niche use case,

but there are many other and much more common use cases

for using tokens.

And so then I generalized 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 the product has a little bit of success.

I love that backstory.

For the hot news,

recently a contributor suggested

a better design for the tokens.

So it's a fairly theoretical argument.

Since I want tokens to be invalidated on password change,

this is a decent way to invalidate tokens,

I'm hashing the hash of the password in the token.

So it's supposed to be secure,

but when you take the hashed password in Django database

and put it into something that will be in URLs,

in emails, in web server logs, virtually everywhere,

it feels a bit shaky.

even if you think you're cryptographically secure.

And so this guy said,

why don't you take just the hash part

and not the salt and the algorithm and everything else?

Then it's more secure

because you have entropy from the salt

in addition to entropy from the password.

So pretty good idea.

But this requires changing the token format

and then supporting two token formats, etc.

So I've been working on this for the last few weeks

I'm going to put out a new release, which will have much shorter tokens,

which will be much more elegant in URL, so this matters to me.

And the trick is that instead of putting the identifier of the user,

so the primary key, a hash of the email and last login date,

and then hashing the whole thing with Django.core.signin,

which produces fairly long tokens, I'm doing a single hash.

I'm putting just the primary key and doing a single hash that encodes all the rest of the functionality I need.

And so the token can be shorter.

Awesome.

Yeah, so I think it's a really tricky thing to spend a bunch of hours trying just to store the tokens for something that makes absolutely no difference in practice.

But they will look better.

I was just thinking, as you were saying, 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 built a prototype of this.

I think 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 I built a simple Django site and I was sharing logins with parents and it's too much.

And I love that you played that out further.

And that's the backstory for this package.

we don't judge people who have children and decide they need to build shelves in their

house or something so we shouldn't judge developers who who think they need to write

their own for the website so we're we're coming a little bit up on time i have a note here to

ask you about django debug toolbar yeah because you were you were you wrote that or you were

you're maintaining it for a while or did you like what's the backstory there because it's

one of the major pieces of infrastructure i i still think i picked it up uh at a time where

it was in need of some maintenance um i modernized it a bit uh probably deprecated some some stuff

that uh that felt difficult to maintain so i don't remember if this started uh because i had

made changes in django that would break the toolbar it's possible that i started when i did

the template stuff and

the toolbar which uses a lot of internal

Django APIs

needed to be updated to account for it

then I

didn't do it for

very long because it's fairly

stable and I think other people

picked up the flag so it was a

temporary thing. Yes, it's part

of the jazz band thing now

the jazz band group. You have

the Python WebSockets

repo

So what's the backstory on all that?

The backstory is that I was working at a company

where we had a project to deploy batteries,

like big batteries to power homes or cars or that sort of 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 ROTC packets or UDP packets felt a bit low level.

And we thought 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 be used for supervision.

So when I started this, actually, I was about to leave the company,

so it was one of the last choices I made,

and I started building WebSockets for this purpose,

also because AsyncIO was brand new,

so it was still called Tulip at the time,

and I wanted to learn it,

and so WebSockets was a way to learn AsyncIO.

Also, since the name was available on PyPy,

I think it was a good time to grab it,

basically name squatting

I'm going to have this name, I need a library

so that was a bit

boldy but I still think WebSockets is a pretty good

library for doing WebSockets in Python

I think

it is

very correct

perhaps not always

super convenient

but at least it doesn't do

weird stuff

it's also very robust

for instance at some point the Python community

discovered that you

had to handle back pressure in AsyncIO

if you didn't want your buffers to grow forever

and

Nathaniel Smith I think wrote

over the past explaining all this

and it turned out that WebSockets was the only

library that did this well so it included

correction in the article. So that was my

moment of pride with WebSocket.

I got at least one thing right with AsyncIO.

So anyway

WebSocket grew with AsyncIO

it has suffered a bit from the

churn in API since AsyncIO

as AsyncIO matured.

And now, well,

it does one thing well.

It gives you a basis for building

servers or clients in Python.

I've been working

on and off since one year

to move it to

a Sanrio model.

So Sanrio was

very fashionable two or three years ago.

I don't know if it's a long-term trend.

While working on this, I have discovered that if you want to do some IOs,

so you have the core part of the protocol that implements everything except reading and writing bytes,

and you do it on both ends, 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 and bytes, or read until the end of line.

And when you use AsyncIO, sure, you are coupled to the I.O.,

but at least AsyncIO gives you a stream reader for free.

Then you start thinking about the writer,

and so you start reasoning about how you are going to write the bytes

to the network eventually.

And so the more I've been working with Song.io,

the more doubts I've had about if it was a good thing.

And so I have a brand that is in the middle of nowhere.

So, perhaps there will be a Sanrio version of WebSockets in a few years.

Perhaps not.

But it's a good learning exercise either way, no?

It is.

The actual reason for doing that is that Tom Christie was working on HTTPX.

And there were discussions about having WebSockets supported there.

So, it could have been done with WebSockets as a core Sanrio thing.

Also, there is Sanic, which is depending on WebSockets,

but the integration is a bit shaky

because I never designed WebSockets 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. Okay, interesting.

So the one thing I wanted,

the other project of yours, which I like a lot,

it's called Django Sequences,

which enables you to, from potentially multiple requests,

guarantee that you're going to get an ordered sequence of identifiers,

which you might use.

The reason I use it is for invoice generation,

if you need sequential invoice numbers.

But perhaps tell us a little bit about that.

That's why it exists.

So you remember I talked earlier about Autolib, the car sharing service,

and then one day

our accounting

which we had written

in the system

gets an audit

and the auditors

come back saying

it's one of the best

homegrown accountings

they've ever seen

because the error level

is

I don't know

it was 0 point something

percent but good enough

but we have gaps

in the invoices

and this is bad

and because

no one told us

you were not allowed

to have gaps

in the sequence

of invoices

and we had them

because of transaction

rollbacks

because we

well we we discovered that when you have a transaction rollback in postgres it can swallow

a number in the sequence of primary keys so general sequences wow fair enough but i mean

it's the sort of thing everyone learns one day i mean you don't know that invoice numbers have

to be sequential but someone tells you you messed up yeah uh so i think we're pretty much out of

time uh is there anything any other projects you're working on or or work things you want

to mention before we go um well right now i'm trying to uh to give uh some maintenance to

most of my patent projects and um well in fact there's a good chance uh that i uh write open

source in other technologies as i'm about to to take a new job which is very good except there's

no django in there uh it's a rails amber and go uh all of which are good technologies i think

uh but uh well probably i'll be writing more ruby and and go and javascript going forward than

python uh perhaps a bit of python for data for data anyway uh since it's going strong there

but well we will see 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

sure well i'm also looking forward to appreciating uh rails uh more uh i've wrote some ruby on rails

very long ago um i think uh 12 years ago roughly uh and back then uh i decided that django was

probably better uh now with a decade of experience uh i will probably have a different judgment

uh probably more measured uh and there's something something that the rails world gets right and in

the jenga world we've been missing and so i'm really looking forward uh to uh well uh seeing

what i what i can bring across from one ecosystem to the other thing i really like about rails is

the controller gives 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 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 i think that's something that we could

try to emulate more in django 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 will you know nice and then the turbo links is built in and it's 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

yes there are some differences in things raised laws and we wouldn't do them in django it's it's

also nice if each framework has its preferences uh that cater to the taste of different people

uh well generally uh python and django has been much more boring uh which i enjoy a lot uh but

again 10 years have passed so perhaps raisins become boring as well uh that's really good

yeah if you if you read hacker news it's definitely boring like django and rails they're

always in the you know people are rediscovering they're like yeah i thought this wasn't anything

but wow compared to this javascript thing django's rails are pretty good that sounds like

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 i really wanted to have on and 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

um thank you for thank you for doing that and thank you for coming on to talk about it

well thank you for having me on the broadcast talk to you soon yeah super thanks all right be well

bye