Transcript: Aymeric Augustin

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

Hello, Will.

Hi, Carlton.

And today we've got Emmerich Augustin with us, who's a longtime Django contributor, member of the uh Django Technical Board and More.

Hello, Emmerich.

How are you?

I'm fine.

Thank you for coming on so much.

You're one of the people who are 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 history, you know, how did you find the project?

And you know, kind of tell me your backstory there.

Uh so it it goes back to 2010, I think.

Uh, and at this point, I was working in a company uh whose favorite framework was Rails, which is a good framework, by the way.

Uh, and then one of my colleagues uh one uh one day tells me about this framework he found that it's called Django, uh, and it's in Python.

And uh so I well I had used a bit of Python earlier in internships, but I didn't know much about the language.

And uh and so this guy, Jeremy Lené, is really enthusiastic about uh Django.

Uh and so I check it out.

Uh and I'm not sure um uh exactly what happens next.

Probably I use it for a personal project or something, uh, and then I stumbled a bug and I discover the bug tracker and I start triaging bugs.

Uh and so people have weird hobbies, some people do crosswords, and uh and I do triage.

Uh and then I do a lot of triage, uh and uh 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 or trying to figure out if something is actually a bug.

Um and uh at one point in uh in 2011, there's a new project where I get to choose a stack.

Uh and so I decide okay, let's do a real thing with Django this time, everything Django.

Um and so uh we we become a fairly heavy user of the framework.

Uh so that was for building Autolibe, which was a car sharing service in Paris.

Uh and so we're uh we're invoicing uh car rentals.

Uh and so we're invoicing by the minutes because it's it's a self-service thing.

You you take a car, you you drop it back, uh and so we need we need accurate billing.

Uh and then since we're good engineers, we uh we start uh uh thinking what happens uh when um uh during the day like savings time change.

Uh are we going to invoice minutes minus 20 minutes if someone takes the car at uh at 250 and returns it at 210?

Uh and that's that's how um uh I discover that Django doesn't have support for uh uh aware day times.

So when you're publishing on a blog and naive date times are just fine, when you're doing a newspaper, which is where you what Django was built for, it's fine.

Uh but when you you're doing enterprise stuff, uh it can be a bit limited.

Uh and so that's how uh I start um uh writing a proposal to support uh aware date time, the date times with time zone information in Django.

Um uh and uh eventually uh this lead up to me joining the team.

Uh so so at the time the the one of the criteria for joining the Django core team was you must have written a major patch.

Uh and so I I had the patch almost written, and uh the team let me commit it.

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

That's like wow.

Uh 1.4 was definitely a big release.

Uh then in 1.5 we we starting uh we started uh working on Python 3.

Uh 1.6 was uh in part partly about making Python 3 work correctly, and then the the next big one uh which was harder to get to was 1.7 uh since that was the new migrations framework.

And also I broke a lot of stuff with uh app loading, uh which I still believe to be a good thing in the grand scheme of uh of Django as a as a framework, but it was uh sometimes because of uh of some upgrade pain.

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

This this one was uh uh probably less significant uh because there were um uh third-party applications that made it possible to use Ginger 2 in Django, which was well the primary uh requirement there.

Uh but having it built in into the framework uh 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 on global state, so so now it's uh a bit more library-like.

Can you talk about so who was 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.

Like I don't uh 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 in you know 2011-12?

Uh one very active contributor at the time was uh Yanis Leidel, uh alias Gestez.

Um so uh well actually he became a core developer a couple years uh before I did.

Uh he contributed to countless uh libraries and also uh a lot to Django Core.

Um then uh at the time um well we didn't have fellows yet, uh this came later.

Um we already had a team of maybe 20 or 30 uh commuters, uh and and and so it the project was uh was still driven uh uh let's say by the second team.

I mean there was a very original team which was Adrian Jacob uh was the creators of the framework.

Uh then shortly after came Malcolm and Russell, who is still around.

Um and uh and so uh and another couple people I think uh but they were less active uh when I joined, so I I didn't uh um need them as much as I did these these original four.

Uh and then uh the the team grew to maybe 20 or 25.

Uh and at this time people were still writing and committing their own code, uh which is something we we stopped doing now.

Everything goes goes uh through the fellows, etc.

So um back then someone had written a patch, uploaded it to track, you took the patch, you tracked it a bit, you committed it to SVN, of course.

Uh so yes, it was a bit different.

So something that comes up every time often 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 they map back and they go they open 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.

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

Something like that.

Uh well I'm I'm a Django core dinosaur, I'm stay aware of that.

Get off my lawn.

Uh and and because things were that way once doesn't mean the only way to do it.

Um one thing we always said we were very attached to is uh anyone uh being able uh to triage bug.

Um and so for a very long time in GitHub uh only contributors who had commit access uh could tag issues, could close issues.

Um perhaps this is a bit theoretical because in fact uh most of the triage is done by uh just a few people, and now most of it is done by fellows, so including yourself uh and Marish.

Um sorry, I I'm not sure this argument holds 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.

Uh and I haven't checked it out.

Uh so now the other things to consider if we wanted to move to GitHub issues um is first how do we preserve the history.

Uh, I've come across a lot of projects who imported the bug tracker to GitHub Issues, and often uh some information is kept, but a lot is lost, many links are broken.

Uh and I think the history in track is valuable.

Very often I find valuable information that dates back for to five or ten years because we're very conscious about writing why we do things in uh in ticket discussions.

Uh and the the other is more an uh open source purist thing.

Probably there's a way to expose 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.

And it'll be like, you know, oh, there's some issue with model form, and you know, 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, you look, this was discussed six years ago, and this comment, and here's why that that and it 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 just GitHub.

And you 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 to track it down is 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.

It's been going for at least eight years, I guess, or maybe ten.

Um and well, somewhat it reinforces that we can we can live with track uh even if it's well perhaps a bit newcomer unfriendly.

Um and then the other argument, uh well, uh the GitHub closed source, etc.

Uh yes, it's a purist thing, uh, but some people feel very, very strongly about that.

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

Well, I did want to mention, I don't know if we have in the podcast, uh, just around new contributors, that Carlton has been doing a lot of work to apply to uh Google Summer of Docs, which Django has been accepted for.

And so they're we're hoping we'll be getting money to have someone to work, 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 that's 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, because I don't know about it.

Well I'm excited about your drum.

And yeah, kind of 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.

And but you know, we're 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.

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, uh, and so if you if you print to PDF the Django documentation, I think it runs 1,500 pages or so.

Yeah.

I think we we raised the bar uh uh very impressively.

Uh now it's still explored 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 I understand uh the the uh let's say um well what's important when voting to documentation, I can see good documentation when I when I when I see it, I recognize it, um uh, but I can't write it myself.

Uh and I I'm not the only one.

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 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 um you know we have these existing this existing site, and then we're just gonna 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.

Um 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.

Um 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 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 a hundred thousand pages, the documentation.

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

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

Uh and one of the things uh uh that was done in the documentation was to separate tutorials from how-to guides um from uh uh reference documentation uh and then the contributing documentation, and and then it grew from there.

But the the distinction, uh the original distinction between tutorial, here's how you get started, how to you want to do a specific thing, so here's a whole bunch of explanations on a given topic, uh, and reference is everything you need to know on this part of the framework, the APIs, etc.

Uh, it was there.

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

Uh now if you come to the docs through Google, you you don't know if you're landing in a how-to uh or in a reference page, uh, and you don't know that the tutorial.

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

Uh perhaps it's a it's uh it's a bit different if you get airdropped by Google somewhere and you don't understand the whole logic, especially when they're 1,500 pages.

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 site maps, for example, I just have a recent tutorial on it.

I want to show the site map part, but I also need to have all the preamble.

And so what I've for 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 gonna jump from this starting point.

So I'll if you need the help, here you go, but I'm not gonna 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, there there's a number of there's the polls app, there's university examples.

Um 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'm you know, there's so much information in the docs that's probably more than could be done um 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.

Uh yeah.

And it's really like gardening.

I mean, uh things have grown, and people are 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 we are facing the limits uh than what um uh Django core devs.

So now we no longer have core devs, we remove 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.

Uh, and so we we freely point people to that tutorial.

Uh and the official tutorial is still there uh because we need one.

Uh, but well, that's that's a kind of local optimum.

Uh and no one has taken the task of uh of explaining what a better tutorial for Django could be, uh, besides the Django tutorial that already exists, so there's no need to do anything about it.

I mean, that's not everything has to be in the Django docs, too.

I like that there's there's room for like content creators to come and add things around the core documentation.

But the other just the other day, I had someone tweet on tweet at me on Twitter, thanks for the docs, they're amazing.

It's like, well, I you know, you're welcome.

I didn't write them, but you know, you're welcome.

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 a in a decent amount of time.

And and this is really hard and prone to to bike shedding, so a bit difficult to do in an open source community.

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 um 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 the site.

Uh 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 out an outcome.

It only comes with time that they find the internals interesting.

It's like they would like to show off all the smart things that they did in the code.

Uh another thing that I find very hard is that when you you write documentation, you you need to stick roughly at the right distance from what people already know.

Uh if you are too basic, well, the documentation is slow and uh and people get bored, and if you you are too far, it's simply not um uh understandable.

Uh and well perhaps if if you're doing a lot of writing for for beginners uh or intermediate people, you you you get a better feel about this distance, but I find it really hard, in fact, to to to to judge.

You have to make an assumption about their 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 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 I kind of know that, but at the same time, I don't I 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?

Because 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?

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.

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've shown you?

Because people come to the docs and it's like, well, where do I get this?

Where is this class?

And it's it's just not shown.

And then as soon as you add as soon as you add the import to the code example, it's become so much more useful.

Um and I know them and I feel bad about them.

Uh so one is that it's usually better to type site colon docs.jjangoproject.com your query in Google than use the built-in search engine, uh, because Google is just better at search engines.

And the other one is when you you hover uh the name of a function in API documentation, you get a link, and in that link there is an encore, and the anchor contains the full import path.

And so this is how you know uh the import path when it isn't written.

Uh that's completely implicit.

Uh and and people have explained in tricks that we're doing this, uh, usually when they ask for making the import implicit, explicit, I mean, uh, but yeah, it it's bad that we're relaying on this.

One thing I wanted to talk to you about, Emerich, was while I've got you on, is the Django stat store static file story.

Because these, you know, back in the day, very much you know, static rendered HTML, and you know, I'm a big fan of that still, and I 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 we there's a single page application and we merge it with React or you know, Vue or some whatever rich client.

And and something that comes up every year, I think, is is what's Django's 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.

Uh and uh Yanis uh has been doing an amazing job there um to bring it to a level where it's very generally useful uh without uh becoming a full asset pipeline that that would have no place in in Django.

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

Um so uh if if we re-win the story, um when uh well originally uh you deployed Django on Apache with mod Python or ModWisgi later.

Uh and Apache is going to store your files, CSS, JavaScript, user uploaded media.

Um I mean user uploaded, well, I mean at first it was a newspaper, so it was editors uploaded images that would get served together with a website, and so Apache says all this.

So one of the first distinctions that crops up uh is that uh user uh provided uh media is not the same uh as JavaScript and CSS, and so this is when uh Django starts separating static files from media files.

Uh this is not completely clean yet.

Uh when you define a form, you there's still a form, a media API which is actually static files.

Uh and well, we could clean this up.

Uh it's not a very big deal, but it's unclean.

Um, so then um uh as the world progresses uh from just stacking a bunch of jQuery jQuery plugins and CSS files as things less like uh SaaS uh appear.

So um then uh best practices uh for managing um scripts and styles appear uh and uh essentially practices uh about cache invalidation.

Um so one uh well the most reliable way to invalidate a resource on the web is not to mess with uh HTTP headers because otherwise a browser that will get it wrong is just to change the name of the file and cache everything forever.

So uh modern static files does this well.

It takes a bunch of CSS and JavaScript, spread out your your Django application, um hashes the content of the file, adds the hash in the file name, and then uh you can serve everything cached forever.

Uh and then if you use white noise, uh you can do everything uh inside your WISIG application with good performance, and you no longer need to care about serving static files separately uh from uh the website itself.

Uh so this is really good.

Um and it's also compatible uh with modern um uh uh JavaScript uh practices uh because if you um let's say you've built a front end with something like React or View or whatever, Ember, uh you bundle it uh with a bundler such as Webpack, this produces a bunch of JavaScript files.

You can uh tell Django uh to use the directory where these files end up.

Uh you put it in static files deals.

Um and then this is how you can uh uh bridge between Django and a front-end framework when you're still building something that looks like a traditional website where uh everything uh is served from the same URL.

Uh and so if you want to optimize this, uh you can uh you can do a few things like avoiding double hashing.

If Webpack hashes once and Django hashes a second time, uh you can also leave with it because honestly it's not a big deal.

Um but very often uh people get confused about how do I uh uh do modern JavaScript frontend with Django, and the answer is just do your front end and then give the file to Django and let static files handle the rest.

Uh and it can uh um result in a fairly simple uh deployment pipeline.

So now if you want to to know all the gory details, uh there's a few uh um uh posts in my blog where I explain how to do this, and I call it the hybrid uh app model because it's hybrid between a traditional Django plus templates, uh server-side stuff, and uh modern um uh browser side uh application.

Super.

I think it's three posts that you wrote.

Uh I found those to be excellent.

I mean, obviously excellent, but it illuminative 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 I recall seeing Jacob Kaplan Moss give a talk on static files at PyCon 2019, uh, 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.

On the other side, you deploy an API, uh, and the only thing you need to get right is um cross-origin uh request uh because the API will run a different domain uh from uh where the HTML is served, uh and usually authentication.

So this is also um uh something uh when I was doing consulting, I've repeatedly uh seen uh people tying themselves into knots uh with this, uh bringing up JWT into the mix, which is honestly not necessary for this purpose.

Uh just uh authenticate with cookies on the domain of the API, it will work just fine.

Uh uh and set up your cross-origin request headers properly.

And uh and in one of these blog posts you just mentioned, there's a uh the whole story.

Uh uh.

And just for those who want further discussion of JWTs, I wanted to ask you about Django 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, that was me!

That was Carlton's.

Of course it was Carlton's.

Um so um, like any uh self-respecting geek, uh, I'm not going to give my photos uh to um 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.

Uh 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.

Uh so anyway, I still like watching my photos on the web, and F3 is not a very convenient way to do that.

Uh, and so uh I built a small application that's called Django Gallery or Mix Gallery because it's just my own, uh uh to have an index of the photos of the database and a few views uh to uh to uh show them by albums.

So very basic stuff and nowhere near as good anything you'd get on any uh cloud-based service.

Uh but it works with my directory of photos on S3.

Uh and then I got children and I wanted to show the photos to my family, uh, and so they needed a way to access uh 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 can click uh and be authenticated with Django.contrib.auth and get access to the photos.

Uh and then there's a super elaborate uh permission uh system in Mixed Galleries that's so complicated that I never implemented it fully.

Uh but that's yet another story.

Um so so Django uh Sesame uh which used to be called Django URL Oath, but there was another Django URL Oth, so I had to change the name, uh was created to this.

Um it's a niche use case, uh, but there are many much uh many other and much more uh common use cases for using tokens.

Uh and so then I generalized the system to support tokens that could expire, uh which didn't matter in the original use case, uh, to support one-time tokens, that sort of thing.

Uh and uh and the product has uh a little bit of success.

Um recently uh a contributor suggested um a better design uh for the for the tokens.

Uh so it it it's a it's a fairly theoretical argument.

Uh since I want tokens to be invalidated on password change, this is a decent way to invalidate tokens.

Um 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 the Django database and put it into something that will be in URLs, in emails, in web server logs, virtually everywhere, uh it feels a bit shaky.

Uh even if you think you're cryptographically secure.

Uh and so this guy says, why don't you uh take it just the hash part and not the salt and the algorithm and everything else?

Uh then it's more secure because you have entropy from the salt in addition to entropy from the password.

Uh so pretty good idea.

Um and uh but this requires changing the token format uh and then supporting two token formats, etc.

etc.

Uh 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, uh, which will be much more elegant in URLs.

So this matters to me.

Uh and the trick is that instead of uh 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.sign-in, which produces fairly long tokens.

Uh, I'm doing a single hash, I'm putting just the prior per 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.

Uh but they will look better.

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 played that out further, and that's the backstory for this package.

So we we shouldn't judge developers who who think they need to write their own for the website.

I have a note here to ask you about Django debug toolbar.

Because it's one of the major pieces of infrastructure.

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 uh and then the toolbar which uses a lot of Intel Django APIs uh uh needed to to be updated to account for it.

Uh then I I I didn't do it for um for uh very long because it's fairly stable and I think uh other people picked up the flag so it was it was a temporary thing.

Um the Jazz Band group.

What's the backstory and all that

to use from let's say modern software so like sending uh road packets uh felt or UDB packets felt a built low level and we thought that WebSockets would be convenient uh to uh manage uh centrally uh and could be deployed in any uh small Linux board uh that uh could be next to the batteries and connected to the battery management system and uh and be used for uh for supervision.

Um so uh when I started this actually I was um I was about to leave the company so this was one of the last choices I made and I started building WebSockets for this purpose also because um async IO was brand new so it was still called tulip at the time um and I wanted to learn it and so WebSockets was a way to learn uh async IO.

Um also since the name was available on PyPy uh I think it was a good time to grab it.

I think uh it is uh very correct uh perhaps not always super convenient uh but at least it it doesn't do weird stuff.

Um it's also very robust for instance at some point the Python community discovered uh that you had to handle back pressure in async IO if you if you didn't want your buffers to grow forever and um 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 include a correction in the article.

So that was my my moment of pride with WebSocket.

I got at least one thing right with Async IO uh so so anyway uh so WebSocket grew with async IO it has suffered a bit from the churn in APIs in async IO as I thinkio matured uh and now well it does one thing well gives you a basis for building uh servers or clients uh in python um uh I've been working on and off uh since one year uh to move it to um a SAMIO model

uh so SAMIO uh was very fashionable two or three years ago uh I don't know if it's a long time term trend while working on this I have discovered that if you want to use SongIO so you you have the the core part of the protocol um that uh 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 uh you need something like a stream reader uh bytes get written to this and then you can ask for read and by

tes or read until the end of line uh and when you use async IO sure you are coupled to the IO but at least async IO give you a stream reader for free uh then you start thinking about the writer uh and so you start reasoning about how you are going to write the bytes to the network eventually uh and so the more I've been working with SomeIO uh the the the well the more doubts I I've had about if it was a good thing and so I I have a branch that is

in the middle of nowhere so perhaps there will be a Soneio version of WebSocket uh in a in a few years perhaps not I don't know

uh which is depending on WebSockets uh but the integration is a bit shaky because I never designed WebSocket for this for being integrating into another server so it would be much cleaner if I did this.

So now it's really a matter of a of whether I I find time and interest to to go forward with this.

in the sequence of of invoices and we have them because of transaction rollbacks because we well we we discovered that when you have a a transaction rollback in Postgres it can swallow uh uh a number in the sequence of primary keys uh so Django sequences but I mean it it's the sort of thing everyone learns one day I mean you you don't know that invoice numbers have to be sequential but someone tells you you messed up.

Yeah.

Uh is there anything any other projects you're working on or or work things you want to mention before we go?

Python uh perhaps a bit of Python for data for data anyway uh since it's going strong there uh but well we will see

back then uh I decided that Django was probably better uh now with a decade of experience uh I I will probably have uh a different judgment uh probably more measured uh and there's certain something that the the Rails world gets right and the in the Django world we've been missing and so I'm really looking forward uh to uh uh well uh seeing what I what I can do bring across from one ecosystem to the other.

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 it's 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 they do things like the Ajax forms which are all 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 that's it's good.

I've never t 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.

Talk to you sooner.