Transcript: pretix - Raphael Michel

hi welcome to another episode of django chat podcast on the django web framework i'm carlton

gibson joined as ever by will vincent hello will hi carlton hello well joined us today we've got

rafael michael hello rafael thank you for coming on the show hi thanks for having me no i'm really

excited to talk to you i so i know you first from um django con europe back in heidelberg um really

but before we get into that tell us a little bit about who yourself about yourself and how you got

how did you find django how did i find django i i think that's an interesting story um i i haven't

thought about it in in a long time um i think i was student at high school and um i was doing a

lot of web development on the side as a hobby and later a small mini job and there was this german

website that

sold t-shirts with

IT motives

and they had

on their Twitter account

back when Twitter was a thing, right?

They had, I think

it was a raffle for

a free t-shirt.

I don't remember what you needed to do

for it, but I entered

into the raffle and

I don't even

remember if i if i won but some of the ceo of that company looked at my website and was impressed by

this 15 year old doing web development and offered me an internship um that i didn't take because it

was in a city at the other end on the other end of the country um but i think that internship

description was the first time i saw that django is a thing and it kind of made me look into what

that is right okay so that's quite good because that's almost like the universe aligning the

planets there for you right yeah absolutely i thought you i thought you were going to say

you'd won the t-shirt i think i've got a t-shirt after all that i'm not sure if i've officially

won it or um but it made me look into into python first and then later into django and then i think

starting 2013 um every new project i touched became a django project instead of a php project

okay so you did you did the php to put django maneuver yeah we should get a support group for

well i think the docs are still heavily there's an assumption built in that you're coming from php

because back when you know adrian and everyone else wrote them that's what that's what the move

was.

Yeah, possibly. Yeah. PHP also has changed a lot, or how

people use it has changed a lot since then. I think they maybe

they used to be quite similar back then. And maybe they are

more similar today than they were in the time between. But

I'm not using it anymore. They said one remaining PHP project

until like two or three years ago, but now it's all gone.

Okay, so I mean, there's two things that linger, right? One

is in the request object you've got the capital get and the capital post from which is explicitly

php and then the other is the uh the the template tag for formatting a date it uses

miraculous it uses the php and so you always have to look it up because it's not like anything else

you use at any other time but well i'm i'm going later this week to see a friend as a meet up here

in boston and a friend who uses laravel and he's just the biggest evangelist ever for laravel

and has been for a while. And so through him, I've been hearing for years just about all the

changes. I mean, Laravel really seems to have given PHP a second wave, if you will. I know PHP,

the language itself, adopted some Pythonic features. And then Laravel, especially for

consultancies, has a lot of features and in some ways is a little bit easier than Django in terms

of cookie cutter kind of stuff.

It has built-in hosting solution.

It's got a starter project

and it has one person in charge, essentially,

which means they can go a lot faster

than we can in Django World.

And at least for some target groups,

the deployment story for PHP is still simpler.

But still, they put your files there and it works.

Yeah, I mean, right.

I mean, that's the original appeal of PHP.

And then I think the fact

that there's a hosted official solution means if you're an agency for sure just and yeah uh taylor

i think that the creator has has talked openly i think it's just a couple big boxes he's got running

millions of dollars a year of uh hosted stuff so just think if just think if django had something

like that anyways so i'd ask you though roughly you've been so you've been using django for well

over a decade now and this this question comes up quite often should we cop should we copy things

from laravel should we copy things from rails should we do you know should we do that if there

are things that stand out for you that we should be doing as an ecosystem that we're not i'm not so

sure um probably something i would need to think about more but also i'm not monitoring the other

ecosystems but well for me django very much fits how my brain works um similar to like in the

javascript word view fits my brain model a lot better than react for example i don't know why

i i've worked with both and one feels natural to me and the other one doesn't and um there is

after a decade i have i've settled in the django ecosystem so much that like it doesn't bother me

anymore if anybody's anything is missing because i have my my strategy how to deal with it for a

while yeah right so you've got your solution and that's what you do obviously there's things that

aren't perfect talking about deployment talking about assets pipelines talking about lots of

other stuff i think uh those are no secrets but um i'm also not aware of other ecosystems where i

would say okay this is i've seen this this perfect we should copy that right okay good let me ask

let me ask you about authentication because carlton and i have been making a bit of a stink

around this recently how how do you like to handle authentication and we'll get to you have

various projects that you know scale and not um that seems to me to be one of the ones where there

isn't there isn't one solution for the community uh so how do you like to handle user auth so the

thing is that i i don't work in the in the agency world with setting up three new projects per year

and needing needing lots of yeah lots of reproducibility or lots of pluggability i work

with long-standing projects that are quite complex

and develop over long timeframes.

And so I find that all the packages

that try to do authentication for you

are too opinionated or too specific

and don't fit into my products as much as I wanted to.

So for the large projects I'm working on,

I'm going with plain Django

and building everything on top of myself or ourselves.

Yes, I have implemented OpenID Connect from scratch before.

It's not something I would recommend.

The tear of blood that drips down as you say that.

We have a few other projects where this bothers me.

We have a few internal tools built with Django, for example.

We run also our company invoicing on Django.

basically on the Django admin, and we have a tool that manages something like a package repository

for the software that we deliver to our clients. It's also a small Django project,

and for those smaller projects, what I'm missing is, for example, good two-factor support.

So I'm using one of these packages, one of the many packages for two-factor,

that i can just like put into my installed apps and it works um and but it doesn't work very well

and it's not very nicely integrated the templates look different and it's it's not really not really

the best thing or the best solution to the problem um i think what i would rather want to see there

would be better low level batteries for that included in django like a base view to do

totp and web authentication and and then have me bring my own templates like i bring my own login

template because it should look like the rest of my application yeah right yeah no i mean that

andrew godwin had this line about the batteries included thing that django should provide the

the hard batteries and let everyone else produce the easy ones and and those kind of low-level

views they're the hard things that you have to get right and then but then the templates you know

there's no reason for us to have an opinion on that no that's super i wanted to we want to go

on to your work and all there but i wanted to talk about you organizing django con europe and

how you you know how you did that and how you found that and you know um how you see django

con europe going forward oh um dangerous yeah yeah yeah no it has to be slightly spicy otherwise no

one listens um so yeah um in 2017 um at the jenga con europe conference in florence uh my friend

tobias and i we listened to the complaints that no one has signed up to the jenga con europe the

following here the eternal complaints yeah the internal complaint and we uh yeah we we put our

hands up and submitted a proposal to do it in my hometown of heidelberg um here in germany which

we which was wonderful by the way like such a lovely town such a lovely venue if you ever got

the energy to organize it there again i'd definitely come back i love the philosopher's

walk the other side of the river good cities to host jangok in european um and i think europe has

so many cities that fit the criteria that we don't need to repeat them yet maybe yeah not yet a few

decades but i don't i don't think we need to repeat cities for jangok in europe yet um but i

think the the perfect location for jangok in europe is uh like um it needs to be big enough

to host 400 500 people have big hotel rooms and infrastructure and travel connections everything

but it needs to be small enough to be walkable to meet people again in the city after the conference

i like the feeling of of going through a small town um going out to dinner with some folks

to restaurant and leaving the restaurant again going to another place and again meeting django

people that doesn't work like if we were doing it in london or something like that it's just

at some point the city is too big it doesn't work um it doesn't work in the way of that but i think

figure kind of works best and so yeah i'm how did i was gonna say how did you find the experience

how was the experience of organizing the conference it was exhausting and also a lot of fun

it was it was hard um because in the beginning you start trying to build a group of volunteers

um that work on it but few people can properly estimate the amount of work this takes before and

um you get a lot of people signing up for it and then not following through and in the end

one of the sad parts of Jenga Con Europe is that in the end, in most years, it came down to one,

two, three people carrying the bulk of the load. And it's not a full-time job, but it comes close

in some of the months out of it. And yeah, that's a lot to take on.

okay and so six years later like you've obviously thought about this and like do you have ideas for

the sustainability of Django we've been you know we've been lucky that we carried on and the Porto

team were great who kept it going over the pandemic period and but it seems like every

year there's this same you know you said in 2017 the problem was no one had stood for well

it feels like that's a familiar story is how how do we how do we make it sustainable interestingly

we've had more proposals to host it recently don't think it's something i can go into too

much detail about um at the moment um but it it continues to be a problem and it's a very hard

problem to solve because we want the conference to travel around europe and we want new people

to come in and do something creative

with that, change it a

little bit, make it better, hopefully.

And, for example, a large

part of doing

it for the first time that makes it hard

is setting up the legal structure

to host. If you need

an association or a company, somebody

needs to be responsible

and, I don't know,

if it ever goes wrong,

someone needs to go bankrupt, probably.

So usually that shouldn't be a person.

It has been a person before,

but it should be a company or an association

that you can have dedicated for this.

And depending on the country,

there's quite a lot of effort to set up,

especially if you haven't done it before.

It takes time, it takes effort.

And it's one of the things that makes it hard

carry a lot of these, like it's not an interesting part of hosting the conference, like assembling

the program, doing social events, but it's the fun part.

But setting up a company or an association is not the fun part of organizing a conference,

but it's one that we need to do every year because it's so complicated for, say, a Spanish

company to host an event in Sweden legally, that we basically need a new one every year

because we want to switch countries.

That's a problem in the US, with DjangoCon US and Defna, it's the same legal association

over and over again.

And it would be amazing to make this easier and have more continuity continue with the

people, with the money, with the processes.

But even though it would be even harder without the European Union, it's still pretty hard.

So that was my kind of question.

Does the EU not somehow, does the single market not somehow make that cross-border thing work?

It's not impossible.

Europython is doing it, for example.

Europython is a Swedish society, and they are currently putting on their event in the Czech Republic.

However, that also means because they're physically holding the event in the Czech Republic,

the Czech Republic has a right to the tax income.

And so the Swedish EuroPython society needs to register as a tax citizen in the Czech Republic,

not so different from setting up a new company.

And EuroPython has, I think, about 10 times the budget of JengaCon Europe.

At 10 times the budget, it becomes more feasible to just hire lawyers and accountants to deal with it.

And it's still a lot of work for them.

It's not just hiring anyone.

They still struggle with it a lot.

So, and doing that at a much smaller budget makes the event more expensive for everyone to attend.

Right.

Okay.

Because you're a Python, it's like a thousand people, right?

I actually have no idea how many attendees they have.

at least 1,000, I believe.

But yeah, in any case,

they have a larger budget for it.

Yeah, I was just going to say,

I recall all these conversations

when I was on the board

of the Django Software Foundation

because the organizers want and need help

and there's always the idea of,

well, maybe we can be under the banner

of EuroPython, which maybe,

but they're also not this huge organization either.

And yeah, it's too bad we haven't figured out a solution because it's so much work just to do the fun stuff, let alone all the money side.

And I recall a lot of conversations around the US DSF trying to set up a European bank account and all these kind of things that maybe we just need to ask EuroPython more forcefully or something.

Yeah, it's not a new conversation, and I'm hopeful we will find a solution some day, and I'm thinking about it regularly, but I have not found one yet.

But there are positive steps as well, right? There's the DjangoCon Europe working group that you're involved with, right, to give people more support.

yes there's a working group and the dsf that tries to support new organizers and to collect

information from past organizers um something that has been going on before as well but now

in a little bit more formalized way but if you say you want to do it for 2027 for example you

can ask the support group any questions you might have about it or if you can have access to past

budgets or whatever um that we can share with you um to give you a little bit of a head start and

we also try to well the support group is quite new and um the current organizers are quite

experienced so it's not happening that much but the idea is also to check in with the current

organizers now and then and see if they actively check in and see if they need any help um or any

further information and just one more thought before we move on if people have got like a half

thinking they think well maybe i could do a django con europe one year they should reach out right

they should reach out they should reach out either via email to the support group or

add a django con or another event to someone who has done it before in person that's

sometimes the more if the more effective way to to get the information that you won't find in

writing um and to get a little bit of feeling about how it works and how to approach it and

I just saw it. So we're recording on November 12th. I know this episode will come out a little

bit later, but just yesterday, all the details around next year's DjangoCon in Dublin came out,

including a date, which is April 23rd to 27th. So I'm very excited about having a date and

Dublin's a great place. Another thing that has been now improved,

finally, that we've also been talking about for 10 years is the planning period has gotten longer.

So when we signed up in 2017 for 2018, we had, I think, 10 months left to plan it,

which is not a lot of time to find a venue and just get everything set up.

Now, the Django Software Foundation has already requested proposals for 2026.

This year, the deadline has already closed.

And so there is the attempt to make the planning period longer,

and that will also make it less stressful, hopefully.

Yeah, it feels like you've got an awful lot to organize if you try and do it in a short period of time.

Well, we also have a new board or we have four new board members that will be announced soon.

And the quality of the candidates was amazing and there's a lot of energy out there.

So I know that having new and energetic and international board members will help with all this.

So that's definitely something to look forward to.

I also want to say, like, we talk about how much work it is to organize these things, but you get so much back, just like anything, when you put yourself out there, right?

I'm sure just for you organizing the event, you meet and, you know, work in a volunteer capacity with people you wouldn't know before.

And, you know, I feel like you get a lot back from any, you know, like we do with this podcast.

You know, we don't monetize it at all, but I feel like just for myself, my happiness with Django and get, you know, reaching out to people like yourself.

So same thing with organizing a conference, the best way to meet people and get involved is to, is to get involved.

Yeah, absolutely.

So you're, there's, I want to ask, you're very entrepreneurial.

You have this company, Rami.io and a couple products.

What is the full suite of, sorry, you know, I almost don't know where to start.

I mean, because you have a number of employees and products.

I was going to say this.

I was going to say, Rafael, tell us about your work, because I know you do some stuff

and it's all in this area over here, but there's a lot going on.

So maybe let's start.

How many employees do you work with now?

Because I heard you mentioned 13, I think, two years ago.

Yeah, we're a team of 21 right now.

You're in charge of that?

You're the main ringleader?

Yeah.

That's quite a lot to do.

We focus on, it used to be a lot of stuff

that I was doing,

but we were trying really hard to focus currently.

And basically our main product is Pretix,

which is a ticketing solution

for any place where you pay to get in,

which involves the entire event industry

as well as parts of the leisure industry,

such as museums or swimming pools or yeah,

Whatever you, wherever you pay to get in this is our target group.

And we try to provide an end-to-end solution with online sales and ticket access control and cash registers and so on.

And the smaller product that we have that started in the pandemic is Venueless, which is a live event platform.

kind of combines live streaming and video calling into into one tool and a few other things

to hold conferences online which yeah is something that we that we come up with to

to help our clients mostly 2020 to 2022 do their conferences at all and now we still have

a number of clients that use it to do hybrid or still fully remote conferences yeah can i ask

about the hybrid nature. Is that holding up? During the pandemic, obviously, it was all

online only. Then the first year back, there was very much a two-stream type thing, online

tickets as well. How's the hybrid thing holding up? Because it seemed like it was a growth

thing. It was a new feature that we should keep.

Yeah, but that's not what happened. The larger part of the event industry has

fully abandoned and went back to in person only in person only um hybrid events are very hard to run

properly um especially if you want to do some proper community management and involvement of

the online audience as well like streaming to youtube is simple but probably making it a

connecting experience out of hybrid event is really really hard it takes a lot more work and

cost than doing either one we have a client he runs a lot of conferences every year and they

decided okay we're gonna do half of it virtual and half of it in person but we're not gonna touch

hybrid it's too hard it's too too complex we also they also want to be able to select different

kinds of content for the different types of audiences and so on so we still have i or we

have hybrid conferences on the platform, but compared to total amounts of conferences that

we work with or that we know, it's a very small number. Okay, interesting. So there's so many

questions. The high-level question is, this is open-source software, and yet you support a team

of 21. And I know you've given a talk that we're going to link to at FOSS back on building a

business around open source applications but what is the what is the short version of how you manage

that right because that seems like the dream for a lot of people the short version is that

most of our customers run events and either they have no idea what open source means and how to run

a django software on a server or they know what it is but they don't have the time to because

So our main revenue stream is providing the solution and software as a service.

We also do all of the other kinds that you can monetize open source software.

We have proprietary add-ons that you can purchase from us that are not open source.

We sell support services, but really 90% of our revenue comes from software as a service

because people just don't want to deal with running the software themselves.

And it makes sense.

It's kind of mission critical for a lot of them.

Like if you're an event business, selling tickets is your revenue stream.

And on the day of the event, scanning the tickets and printing badges is a very important part of your user journey.

And you don't want to deal with a silver outage yourself in that situation.

Yeah, right.

So when I look at the Git history for the project, I see January 2015, I think, is the first public commits.

The question is, when did you...

I think it's September 2014 already.

Otherwise, we would have hosted our birthday party at the wrong date.

Well, maybe I'm doing my searching correctly.

But I guess the question is, what's the story of that, right?

I mean, because it was you, right?

You had this inkling and you put a lot of work into this product, not knowing that you'd be where you are now.

DjangoCon Europe is not the first community conference that I co-organized.

I started to get involved with a local conference.

It's called MRMCD.

It's from the local, let's say, privacy and open source community.

And somehow I raised my hand at the question of who's going to deal with ticketing money.

And so I fell into that hole.

And there is not a lot of open source software to deal with such things out there.

And we tried one or two, and it was all bad.

And so I decided I'm going to start my own.

And I consciously, because in that community, there's a lot of homegrown software that someone

maintains for two or three years, and then it's no longer around, and nobody cares about

to suffer anymore so it was a conscious decision to try to do it in a way that allows me to make

it sustainable um it was never the plan to build a company with 20 employees out of um but it was

the plan to somehow monetize it to keep it alive and can i ask because you start something new and

you look at what's out there and you think none of these are any good but they've all got more

features than like you realize that you have to build when you start right like you think oh you

know i could get this build up quite quickly but then you realize oh it sends emails and it's got

this and it's got that and how how long did it take before you it started to mature so you start

to think i actually it's it you know obviously there's always more you can build and always

things you can make yeah absolutely

we're not done yet right um but but how long and so first commit i think end of 2014 um i was

running my own conference so the one that triggered the creation on it june 2015 so

okay eight months later and i think the first event that was not run by me with a lot of

patching on the job was a year later early 2016 when we launched 18 months or i i launched the the

soft software as a service version i think january 2017 so a full two and a half years after the idea

for ticketing in the united states anyways we have this company ticketmaster which is i'll go

on record as saying pretty much evil and not only are they expensive but they're also they don't

work all the time. So I know that, you know, when you have challenges of these big spikes

of traffic, right, where nothing, nothing, nothing. How did you originally tackle that?

And I'm sure that's a huge issue now, right, when you have very irregular streams of usage.

Yeah, absolutely. So that's one of the hard engineering challenges in ticketing,

and it's not one we solved either. I believe it would be quite feasible to

build the ticketing system that scales almost infinitely if you would constrain yourself to

a very small feature set and a very specific use case but that's not what we do we have a very

extensive product with a lot of complexity um think about and and a lot of the problem is that

you don't only have these these large load spikes but you also have to deal with scarcity all the

time so for example if you have a theater ticketing where you can choose your seat there is only one

seat five in the first row i can't go infinitely concurrent and run the system on millions of

servers that are independent on each other because i can only sell this seat once um sorry i need to

actively prevent concurrency um in a way so um yeah well i was going to ask so do you so okay so

do you take a kind of command query type approach where you like you you request

the request made to the django request isn't a buy ticket it's a request to buy a ticket and

wait for a response yes so all ticket buying um requests go through a salary queue

in Pretex, so it's just

a task that can be retried

and can wait on a

queue, and we

use

PostgreSQL's

advisory locks now

to have a

very lightweight way of saying

you can place a lock

on this seat, on that quota,

on this voucher,

on all the kinds of things we want.

So we

can but still this locking limits us in how many tickets we can we can sell um at a time um because

in principle we can only sell one at a time um of the same type if we need to

take care of such conditions so we're limited at around a thousand sales per minute or something

like that for a given event because that's just how fast we can we can get it right now um and

the industry startup solution that's not very different to what ticketmaster and others are

doing is like if you if you go beyond that you have kind of virtual waiting room where you say

okay this website is a little too much load please stand in line and we'll let you in soon okay you

do all that so i mean i've seen you give a couple of good talks at jango cons i mean not because

good talks great talks um one on scaling channels in edinburgh which i just thought was the best

channels talk i've ever seen so i do recommend that and then it's been that much uh to be fair

but the the other one this year was about the debugging um slow um slow database requests

in production because that's the key right it all working fine locally but then but they're not when

you get it out there live yeah absolutely just just the other week we had a slow sql query was

yeah only debuggable in production i think we we found a postgresql backup but not too sure yet

can i ask a more detailed question which is so with your team how do you you know how do you

all set up your local machines are you using docker or how do you you know all work on the

same thing say most of us quite old school with um virtual environments and manage.py runs over

so for pretix it's really um really quite simple um for venueless because it's a few more components

we have a docker composed setup um but uh yeah my my local predix development is just a virtual

end with a package installed i mean the great advantage god the great advantage of the vm or

the docker system is supposedly it's the same in every environment do you find do you find there's

these cases where running locally doesn't don't forget like we we're not doing exclusively software

service we also have clients and open source users out there running our software on different

machines so having a little bit of chaos in the development around as well might even be helpful

in ironing out those edge cases that's that's very true we actually like i i develop most of

the time i develop um on sqlite and we run on postgresql in production i love that wow it has

some challenges, but, you know, it helps to keep some flexibility and surface some bugs.

So then you must be using quite large fixtures to populate your local databases.

Is that how you're doing it?

How are you working on the same stuff in the team?

No.

No?

How do you do it?

A colleague now set something up, a pretty steamroller plugin where you can define the

system settings in a YAML file, and then a small tool applies it through the API.

But a lot of it is just run it locally and click through the different cases.

Okay.

No, you said API are using, and you mentioned Vue earlier, are you using a Vue front end, an API back end?

Is it all service rendered?

No, it's mostly traditional Django forms and Vues.

We use Vue, so we have an extensive API that we use both internally and externally.

And we have a few parts of the user interface that are view-based.

For example, the seating choice element or some other stuff.

We have some more complex user interface parts where we use Vue to build a more interactive component.

But the major part is plain how Django was invented.

And are you using Django REST framework for the APIs?

Yes.

So you've resisted leaping over to Django Ninja and some of the newer Sizzle things?

I am quite resistant against hopping over to the new shiny thing when the old thing still works.

And I have thousands of lines of code with it.

Yeah, it's one of the challenges now after 10 years, some things are not that easy to change.

But that's natural, right?

Yeah.

I was talking to Carlton earlier.

I'm finally updating my, I have a book on Django for APIs with Django REST Framework.

And Django REST Framework is in an odd place in that it's feature complete.

And yet, so it doesn't, it's not the shiny object and yet it's used everywhere.

And actually, Carlton, that's to you.

You helped with the 3.15 rollout, right?

Like, what is, are you still officially a maintainer of JGRS for now?

I'm still on the team there, but not really doing very much.

I don't, you know, if I'm pinged on an issue, I'll, you know, I'll comment, I'll join in.

But it's, the thing is, it all works, right?

Okay, so let's look at going the REST framework folder and we look in the generics.

Yep, they're all 100% battle-tested, and look in the views, they're all battle-tested.

Look in the serializers, they're all battle-tested.

And the trick, the bit that people want changes for, they want tweaks for, is in the serializers,

because there's a weird behavior.

If you've got a null field here combined with that, does it serialize exactly how you would want?

Maybe it doesn't, but at this stage in REST framework life, that bug, if it's a bug, it's almost unfixable

because people are relying on the current behavior.

And so you can't suddenly make it return true rather than null or none in that case, because that would break people's APIs in production.

And so those small, those really small kind of just character bugs, they can't, they almost can't be addressed now.

So what's the solution?

I don't know.

I don't know.

But REST framework is as reliable as it's been for the last decade.

It's just not going anywhere forwards.

Like, that's the, there aren't going to be massive changes to it now, is all.

Which is good for your book, though, Will, right?

Because, you know, you can update it more easily.

Yeah, no, I mean.

For a project like ours as well, like, why would I want a new major version that breaks a lot of stuff if I don't have a lot of requirements that it doesn't fulfill?

Well, that's the other thing, is what would be the major feature changes that would justify a breaking change in REST framework at this point?

And there aren't any.

Well, so I have to ask Raphael,

HTMX, right?

I'm sure you've had discussions around this.

Where do you and your team sit on

switching some of the Vue things over to HTMX?

I must admit, I have obviously heard about it

and seen it and briefly looked at it.

We haven't really tested it in the project.

I don't have a strongly formed opinion on it yet.

Okay, fair enough.

I mean, it does. And you're in a different situation with a very tested product team. It does seem the advantage is if you're a one or two person team, you can get a lot of the reactive behavior without having to split things up and do front end back end.

It's interesting that there's now, there was a post, right, there was a post about too much HTMX, I think, that got a bunch of traffic, you know, because it's not, obviously, it's not perfect, right?

So people are finding the box in which it seems to work best, right, where solo developer, great, but then there are, of course, these limitations, just like there is with any tool.

yeah absolutely and and there is like um i i studied physics at university and physics is a

lot about a lot about laws about conservation conservation of energy conservation of momentum

but there's also conservation of complexity and if you're trying to build a complex thing you're

gonna have the complexity on some layer and you can like in different situations and can be a

bit better of having more of it on on a different layer but it's not going anywhere yeah and it's

it's kind of like you can shift it around one place or the other but you said before about

django fitting your the way you think and view fitting the way you think that that's kind of

the way i'd describe htmx for me is like the reason why i like it is because it fits the way

i think and it fits the django way i think and so it's you're exactly right it's not about reducing

complexity it's just about going along with the way your mind works or not you know if you do go

along with the way your mind works it's for some sense easier for a while all right so i want to

i want to ask you sorry then you can go carlton so managing a team of 21 people and a very popular

product i guess was that something you expected when you were starting out as a programmer were

you thinking i want you wanted to be a business a business owner no no no no no but you're still

you're still happy you're still doing it right because sometimes people

don't want to do that so what i what i love about it is that i have to deal with entirely new

challenges every six months um so i approximately everything six months i'm learning something

entirely new but i've never done before and i need to do it now and i need to understand it

and um that is very exciting to me and um so far it's a lot of fun of course the things that i do

day by day have changed a lot um i still spend a lot of time coding but i also spend a lot of

time in meetings um internally with clients with suppliers with partners and stuff do you have to

defend your coding time do you have to like yes yeah insist on yeah absolutely it's not so hard

to find time for fixing bugs and other smallish urgent things because they appear to be urgent

time uh appears but it's it becomes quite hard to find time to work on larger features or

larger projects.

Luckily, I now have other very capable team members

to do that as well, but I still enjoy it.

And I'm also, I believe I'm still useful when doing it.

On the running a business front, it must be, well, is it deeply rewarding to think that, you know, giving solid employment to 20 people, 21 people, you know, that's quite a nice thing to put out into the world now.

I like two things.

So it's also a lot of work and also comes with some challenges and not without, like, yeah, but yeah, it's nice.

result to get from from just starting an open source so you said um a while back you said

that 10 years in it starts to get harder to make these changes how do you how do you sort of try

to manage that long-term tendency to you know because if you know if you don't manage it you

grind to a halt eventually how do you manage to keep momentum so we try to stay very up to date

with a lot of the dependencies that we have.

However, that means we're not going to bother

with Django releases that are not on LTS.

It's just too much work, not worth it.

So we're upgrading 3.2 or 4.2,

and we will next be upgrading 5.2.

We have the additional challenge

that Predix has this plug-in architecture

where you can install additional functionality as a plug-in.

So when we do a major upgrade like a Django upgrade,

need to do that in around 120 repositories at the same time which is trivial for some changes like

replacing you get text with gut text in the imports and absolutely not trivial with a few

other changes like delete form a delete view suddenly working differently um yeah right

um so i remember i remember that i thought yeah that's fine that's fine but there's a few things

um but we we haven't figured out yet we for example um our our html and css is based on

bootstrap 3. and i'm not sure we will we will never i'm pretty sure we will never upgrade

from bootstrap 3 we will migrate to something custom built but tries to give a backwards

compatible journey because the effort of migrating, I don't know, 5,000 templates to

Bootstrap 5 just to do that again for Bootstrap 6, it's not going to work. So with a few things,

yeah, we'll need to find our own solutions for that.

Okay. So my last big question is I want to ask about Stripe and billing, because I think you've

been using stripe from the beginning at least since at least since 2016 maybe earlier it's

yeah it's one of the i think today 25 payment providers we integrate with um and it's been

the first that we that we've integrated together with paypal i believe so that's on a very small

project of mine i was just integrating stripe and i've done such integrations over the last

seven or eight years and Stripe changes all the time with how they do things. And I can't even

imagine all the payment providers you've got to deal with. So I guess the question is how

do you manage that, right? Because dealing with money is important to a business and you don't

want to get it wrong. And yet it seems like so much to juggle. That brings me to a feature that

I would love to have good support for Django REST

framework, because what's really amazing is

how Stripe deals with API versioning, I believe. I think they have

found the sweet spot for how to

version an API when they do

breaking changes, because basically you can

set a request

header but specifies the api version you are aware of and it will emulate the behavior of the past

api as long as absolutely possible so um stripe is changing a lot but actually we there have been

a few larger changes over 10 years but most of the time the changes are don't require a lot of

action on our end we also only use the payments part of stripe we don't use their bill is billing

or invoices products because these are all things that we have in our product as well we have our

own invoicing and module and so on um i'm not quite sure anymore what the question was um but

um yeah so most of the payment providers are not that hard to maintain because they don't change

that much but they need to work well of course um because yeah people are are interested in

getting their payment yeah they seem to care about that i don't know why one more one more

small question um so to store money integer field decimal fields positive big integer field

how do you like to do it yeah so we we use decimal field consistently okay that works

um the arithmetics with decimal field are what you want for money unless you're on sqlite but

we don't use that in production um decimal like sqlite doesn't have a decimal field in

it totally stores it i believe as a string and then there's weird things with it when you try to

do computation on it but on postgreSQL i believe decimal field is a good fit

except that we will not be able to properly invoice in about seven of the currencies in the world

because we have money stored decimal field with two decimal places.

And there are, I think, seven currencies in the world that have three decimal places,

mostly in the Arabic countries.

And I'm not sure if we're ever going

to be able to properly migrate those fields.

We had the problem already.

We had 10 digits and two decimal digits

we already needed to migrate to a larger decimal field,

because I don't remember which currency it was.

Some currency where you have these very large amounts,

where you would buy conference tickets for a few million.

But in the end, these differences are why I feel or why I'm quite happy with

using decimal field, because if you're storing it in, so floating point is

wrong, we can get that out of the way.

As floating point numbers from storing it as integers brings you to the same

problem because American projects is usually integer of sense, but now you

look at the danish krona which doesn't have a decimal part of the japanese yen or or you look

at the jordanian dinar which is three decimal places and now either you would need to globally

multiply by a thousand even though that gives you integer representations of things that don't exist

in u.s dollar or you would need to have different multiplicators for different currencies which

sounds even worse um so the the complexity there with the internationalization is the same whether

you're storing it in decimal fields or integers um there are a few advantages or disadvantages

to either one well i'm about to launch something so maybe i'll switch to decimal field because i

have been using integer but so the really really bad thing is that a lot of the payment providers

like PayPal or Stripe,

they specify in their API,

please submit the amount in integers

of the smallest denomination of the currency.

And there are some currencies,

like I think the Danish krona

technically has the decimal point

with two places behind it,

but it hasn't been used in decades.

So, and they don't publish

whether they consider

if the currency with decimal places or not.

So depending on the payment provider, you might need to multiply it with 100 or not.

So whatever you do, document very clearly how you want other currencies to be handled.

Yeah, well, it seems like it's like time zones.

It sounds like, oh, money is money, but just like time zones are not time zones.

It's quite complex.

We store the time of an event as a Django date time, but it's time zone aware.

But technically, that's wrong.

We should be storing local time on a place because if the time zone legislation changes

because we're dealing with events in the future, like DjangoCon 2025 is going to be in Dublin,

Ireland could abolish daylight saving time before it happens.

And then all the timestamps in our database would be wrong, and we would need to manually

fix them for all the events that are taking place in ireland um so far that hasn't happened but yeah

there's so much hidden complexity here good the other day as well your um i18n field came came

up which is a solution for storing multiple languages of multiple text translations in a

single field right yeah so we there's quite a few things in critics uh where we are doing

things maybe a little bit unconventionally and published our package one of them is the how we

store translatable strings so if you are hosting a multilingual event you can also give the event

a name in each language and set up email templates in every language we have a custom field type

that allows doing so that is django i18 unfilled and there's also django scopes which is our way

of separating multiple tenants in the same Django project,

in the same database.

I've given a talk about Django Con Europe 2019 in Copenhagen,

I believe, or no, 2020 online.

I believe it's on YouTube.

And we also have our custom package.

It's called Django Hierarchy, but it's our setting store.

We have over a thousand settings that you can use to configure your ticket store or shop.

And we don't want to do model migration every time we add one.

And it's also like with the plugins and so on.

So we have this in-database key value store that has a hierarchical dependency because you can set things on the tenant level, on the event level, and even on the global level.

it kind of trickles down you can um you can uh inherit the settings from an upper layer so

there's a number of of small django packages that we maintain because yeah it's useful for us and

maybe for for someone else as well but like you um you said that they you did it in an unconventional

way but these are kind of battle-tested ways they've grown out of your actual needs right

And so, you know, you might, the I18M field, you might not want to store the repeated blobs in the same field, but, well, actually that works for you and it's simpler for fetching, it's simpler for various others.

Yeah, absolutely.

Well, we're getting a little bit close on time. Is there anything, you know, we haven't asked you or that you wanted to bring attention to?

No, I don't think so. I'm prepared for the question.

Well, that's our fault. I mean, normally we would ask something around what would you change in Django, but I think Carlton led off with that early on. So, you know, the magic wand, right? What would you change? Is there anything else that comes to mind in core Django that you'd like to just make so?

So for REST framework, as mentioned, API versioning, that is really helpful on both ends.

In core Django, yeah, I think what we talked about before, I think we need built-in batteries for two-factor authentication.

It shouldn't be something you add extra time.

not so sure about single sign-on

OpenID connect someone, because that's

very complex and that's very

that's also

changing landscape, but

I think

we really need, like

if I install

Django and set up a Django admin two-factor

authentication should be the default.

Should be

fully integrated, yeah.

And there's no reason why Django

couldn't ship some kind of

adapter layer, like, you know,

Like Django could define the interface that if you implement that, then you could add your auth flow for, I don't know, logging by whatever.

Yeah.

All right.

Well, I feel like we could ask you questions for another couple of hours, but it's a really impressive thing that you've built, I would say.

You know, open source project, organizer, team of 21, and maybe most impressive is finding the time to still code yourself.

I think maybe that's part of why you seem to enjoy it.

Sometimes people have monetary success, but if they get moved away from the engineering or core work that they really enjoy, I've seen people who don't really enjoy the success of their companies when they're in meetings all day long.

Yeah, it's understandable. So far, it's for me.

Great. Well, we'll have links to everything, especially your talks, which your talks are fantastic on all these topics we've mentioned.

And hopefully I'll get to see you in DjangoCon Europe next year.

Are you planning to attend in Dublin?

I'm not so sure yet.

But the year after, definitely.

Okay.

Fingers crossed for that.

Fingers crossed.

So we are at DjangoChat.com and we'll see everyone next time.

Bye-bye.