Transcript: Django Unicorn - Adam Hill

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

gibson joined us by will vincent hello will hi carlton hello will and today we've got with us

adam hill who's a long-time developer and author of django unicorn and lots of other exciting

packages i'm home to talk to talk about today hello adam thank you for coming on the show

hello i've been listening for a long time so uh normally it's at like two times the speed so this

is a little bit different but um i'm excited to talk to you guys i really appreciate you uh be

slightly lower pitched that's right that's right that's good so we always ask him i'm um i don't

want to jump straight into django unicorn she's got lots of other things so we always ask about

the backstory and you've been around for a long long time so perhaps you can tell us how you got

to programming how you found django you know what's your origin story hi so um yeah i've been

programming for over 20 years so i've been around for a while um and in my day job at the molly fool

um we use c-sharp and a lot of the microsoft stack um and so can i before you carry on that

i want to ask you so this i'm always fascinated by the microsoft stack and the c-sharp stack

when you're working when you're working on django what are the sort of bits that you miss what's

what's the really nice bits of working in that in that um ecosystem in the microsoft stack so

um i mean i started working in django because i wanted to get away from the microsoft stack

uh but the nice thing about it i guess is that it's sort of all integrated uh with each other

if you're on windows use sql server use um you know um just the whole the whole stack together

whereas Django you kind of have a little more flexibility and with that comes a little more

choice so you have to choose Postgres or MySQL and you have to choose Gunicorn or you know what

what your serving uh platform is so it it becomes uh you know there's there's just more choices

there okay but there's not one bit that when you eat like even today you come with Django and you

think oh do you know that bit from the from .NET that I wish I had that I wish I had I don't

personally i'm sure some people do that's a good that's a fair answer i'll accept it okay so anyway

you're at motley fool programming c sharp you think yeah so i'm looking around it's like two

you know 2010 and um you know all the all the fancy startups are using ruby on rails and they're

kind of outside of this ecosystem um but my friend uh introduces me to someone who wants to start a

startup which uh is for house auctions so it's the idea is about as dumb as it sounds um it's like

we're gonna start uh you know a house auction at a dollar and let people bid and then they get a

house at the end um so i was ahead of your time ahead of your time i think right that's an open

door and stuff too sort of um yeah i was i was like well this this might not work out but it'll

be a fun excuse to try something different outside of the whole Microsoft ecosystem.

And so I was reading about Rails, and I was reading about other frameworks, and I came

across this Django thing, and it was mostly, I think, the ORM, and at the time it was South,

which you could do migrations, and I was like, mind blown, like, I don't have to manually

write stored procedures, like, sign me up.

So I tried working with this startup for a while, and I used Django at the time.

I think it was 1.2, and I really loved Django, and I found all these things that I really loved about it.

And I found out that the startup was not going to work out for all sorts of reasons, but that was fine.

And so that was my first introduction to Django.

And then around 2011, our CTO at the time kind of looked at a couple of us techies and said, if there was any tech stack that you would use, what would we use?

If we were starting from scratch.

And so I advocated for Django at the time.

Some other people advocated for Rails and some other things.

How did you sign up Pistols at Dawn?

Yeah, that was basically it.

so it was a um i don't remember it was so long ago um it was mostly a conversation it was like uh

let's try this and let's try that uh and i maybe i just convinced a lot of people um that we should

we should try it out but um so so so does does the is the long and short of that that the motley

is built on um django these days or yeah so most of the user facing site is uh is in django uh we

have some backend services that are still in C sharp because, um, you don't want to have to

rewrite everything and they still work and it's perfect. Um, and we have some WordPress sites as

well. Uh, so it's a couple of different technologies, but most of what you see when you

hit the site is all served from Django. Okay. Super. Can I ask about Python? Had you used

Python before Django or cause that's also a big part of the Django experience as opposed to the

microsoft stack you know i haven't um or i didn't uh i think when i looked at uh when i was evaluating

other frameworks python was a big uh point in there it was like oh i really like the way that

this looks it was aesthetic um and and sort of the ecosystem around django and python even at that

time it was still like oh there's all these packages that i can use and pull in and i don't

have to rewrite all this stuff that was really appealing to me yeah i think because for me i

think it was around 2010 ish when i i got into programming and i was in san francisco and it was

rails django and really i waited it rails was way more popular but i thought python looked better

to me than ruby and also even then had more applications um and so yeah i'm always interested

to hear what you know but you know because a lot of people they come into their first framework

with no knowledge of web frameworks,

and so they kind of blame the framework

for the learning curve of that.

But if you already kind of know how websites work,

you skip that blame, right?

It's only kind of like your second or third.

You're like, oh, maybe it wasn't Rails or Django

that was so hard.

It's just the web is a little bit trickier

than I gave it credit for.

Yeah, it turns out these things are just hard in general.

Yeah.

That's why I tell, like,

I generally don't deal with technical people

in my personal life,

And sometimes they're like, well, there's like hundreds or thousands of employees at

these companies.

I'm like, yeah, well, if it was easy, you know, cause they're like, well, you can build

Instagram in a weekend.

I'm like, yeah, for like 10 people, but like, you know, a billion, there's a reason it gets

a lot harder.

It's always the scaling that becomes tricky.

Right.

Yeah.

It's like one or two front end, a couple of Django and then DevOps infrastructure.

Yeah.

Yeah, for sure.

Sorry, Carlton, you were, you had a thread of questioning.

well adam i want to speak to you about um your open source packages a sort of the main one now

um which way around you want to take it you want to do unicorn first or last sure

yeah that sounds good

you've become first or last uh first first it's fine okay let's talk let's talk about

django unicorn then for people who don't know it can you tell us what it is and then we can discuss

you know various aspects around it sure so this short pitch is basically it's a reactive component

framework on top of django so it basically lets you have a python class and a template

and they kind of are tied together they're bound and you can render that python template

inside of a regular Django template.

And then you can have attributes on the HTML.

So you could click a button

and it will call something in the Python class

and then re-render on the front end

and things have changed.

So that's the easiest way to explain it.

And when you say reload on the right,

it just reloads that bit of the page, right?

Yes, just that little portion of your template.

And you can actually target,

even if you want it smaller pieces,

to like reduce the payload um but basically you know when i was looking around at at things um

i don't know if you've seen like uh elixir's uh live view yes uh so basically they use web sockets

in the back end and they do this sort of reactive uh functionality and i looked at it and i was like

you don't have to write any javascript to have interactivity on your website that's like

crazy, right? And I kind of wanted that for Django. So I actually built a prototype using

Django Channels, which Carlton, I know you work on. And I found it more cumbersome than I wanted

it to be. So I didn't want to run Redis. I didn't want to run a separate process. And so I was

looking around a little bit more and in phps laravel they have live wire and instead of web

sockets to you know make that interactivity they use regular old ajax requests so it sounds a

little when you first think about it you're like i mean you're going to make an ajax request for

every update and then you're going to pass back html from the server side some people are like

that doesn't make a lot of sense, like it's not going to be performance. And, you know,

why would you do it when you can just use these web sockets? But the upside is that it makes

deployment really simple because you're just it's just Ajax. It's it's already what the server is

dealing with. And if you look at sort of GitHub or there's other examples, but GitHub is the

canonical one. If you watch the network inspector, they're passing back snippets of HTML. It's not

json you know with some spa on top that's re-rendering it uh so it's a it's a pattern that

that lots of big sites use um and unicorn basically uh it gives you an easy way to do that

without wiring up all the bits uh by yourself um because i know in django right now uh htmx is

really hot and people love it and i love it too i've used it on some of my side projects um it's

really great and carson is uh you know an awesome developer and a great advocate for this this style

of uh web programming i guess um but you still have to create your urls uh create new routes

you have to make sure your templates are set up in a certain way and so the one thing that unicorn

does is it kind of handles it all i call it it's magic um but you know um it basically it gives you

a pattern for doing that sort of thing right so that was the question i was going to ask so this

this html over the wire thing so the the rails they use the the hot wire right which is their

version and then um htmx has been has blown up it's very big and i was going to ask you

so you're in exactly the same sort of um place the same strategy what you know can you just go

over again what is the selling point of django unicorn versus htmx for all the folks that have

seen that htmx explode and a bit on that what do i get extra when i come and check out um django

unicorn what would be the selling there yeah so the the selling point is that it um it sort of

gives you this little pattern that you can add interactivity easily to your site without having

to wire up all the manual bits. It also integrates, it's basically Django aware, right? It tries to

play nicely in the ecosystem. You can use Django messages inside of your Python class and things

just work sort of as you expect. Validation works the same way. You can use forms. It basically,

it knows about Django. And so it can be a little bit smarter about what it's doing.

There's support for Django models and query sets. You know, I try to just sort of integrate it into

the whole, you know, ecosystem. So it feels like it's part of a Django project, as opposed to

um something that you kind of add on and then have to fiddle with i want to mention that you have i

think two screencasts now with plans for more where you go over like a basic those are those

are great like because it's exactly that question right i'm sure i saw like i've researching this

episode on reddit and other places everyone asks you well why not htmx and you know i feel like

those the two you have certainly show it and then the plans for more um kind of eager i hope you get

a chance to do those as well yeah it turns out screencasts take way more time that's why i don't

do them they're so it's not it's not just sit down and no so yeah i mean it's just like a conference

talk honestly it's but it's three minutes as opposed to you know 45 or whatever uh but between

trying to write out a script and make code that makes sense that i can show and then finding a

quiet space in my house that i can record it it's like i'd rather write some code and just like

put some new features out there as opposed to making a screencast so uh you know that's my

own fault well i think that's every developer right it's like you you build this thing and then

the demands are like nine out of ten the selling of it rather than the doing of it so yeah i mean

i have a blog post in my head about sort of like open source and how um you know just writing the

code and getting something out there is like just it's the first step you're you're at like step

zero basically at that point and then um a lot of the you know the um where unicorn sort of like

caught on a little bit was more on the marketing side so like i built the whole site that has

little you know small demos that people can play with and see and um you know i went on reddit and

i tried to advertise it a little bit and so you know there's a there's that whole other part of

writing code when you're in the open source ecosystem that like people don't really think

about or or maybe don't want to to work on because it's it's the less fun part and i know you're

building the bookmarking site dev marks io is that built with unicorn yeah it uses a unicorn

um basically i have side projects so that i can dog food my own side projects um so it's sort of

like turtles all the way down um or the hair the hairiest jack in the world with one way or the

other so dev marks uses a unicorn and a bunch of my other libraries um and basically i just wanted

to make something uh to store all my github stars i mean that's basically what the genesis of that

project was because, you know, I wanted to have a better interface that I could see all

those stars and I could sort of attach notes to them. Now they have lists in GitHub, which

is kind of nice. You can organize. But yeah, I wanted someplace where I could, you grab

all that stuff and i was like well if i'm getting github stars there's probably other things that i

could also pull in and uh bookmark uh for later um so there's like hacker news favorites and um

there's all sorts of other sites that i sort of integrate with but that was the plan so that's

deadmarks.io is the url there and that's free to sign up for and yeah do you have plans to

go on camera go ahead oh no yeah it's free um you can sign in with uh github uh and yeah there's

there's plans to monetize it if you want to pay me five dollars a month uh feel free you can

um but for you know for for most people uh they just use the the free side and that's that's fine

too it's most of my things are to scratch my own itch um so i don't i don't think i'm ever going

to make a whole lot of money off of these things i have a day job that's fine that's how i that's

how i survived so it's all good what i was going to ask is do you have any thoughts on the um i

have a sort of i bookmark a lot of sites you know i've got the key key command i see that see that

it's kind of like an append only list in that they go onto the list and it might be like five

ten links a day and it saves me having to read them there and then but the reality is i very

rarely go back to a process like this. I mean, I think that's normal. I've spoken to a lot

of people that have the same phenomenon. Have you got any thoughts in how we might use something

to surface this?

Well, Carlton, I just want to add that Jeff Triplett, who I do the Django newsletter with,

was jokingly saying, maybe I should just publish all my tabs I did or didn't read on Twitter.

And I think a bunch of people are like, yeah, I'd like that.

Yeah, tabs I've got open at this date.

yeah yeah i don't uh i mean i i have no help for you because i have the same problem but if you

figure out something i would love to hear about it okay okay i don't know i'm hoping somebody's

going to come up with something that will just say oh you know you've bookmarked a site on this

three years ago carlton you're so like you know monastic in some ways reading kant at night you

just got to let it go and just you're never going to read them like i don't you know i do like i

start the day and it's just empty because i don't even pretend i don't want that burden of like i

should do this right but this is this is why i use it so i used to have this problem where i'd have

like 4 000 tabs open and i can never find any any and i just keep them open at all and so what i

decided was if i just bookmark every single site that i see um the idea that strikes me interesting

every site that i would leave open in a tab i bookmark it and close the tab and it's amazing

because now i have like one two tabs and you know it's really hectic end of the day there might be

10 tabs but i never have 50 and it's like a closed loop because if you've got an open tab

it's constantly sort of in your decision cycle going do i need to read this now do i need to

yeah it's an endless loop yeah but like you recursive loop or something you need

you i do i use a search history so like yeah very often i'm like oh yeah what was that thing i wish

i hadn't closed it and then i just go into my search history and and there it is okay so we

We'll do, listeners, we'll do a listener shout out to ideas if you send in postcards.

It's a tension, though.

It's a tension between, you know, endlessly curious, which I think many good developers

are, and then, you know, not getting bogged down with trying to learn everything, right?

I think especially for people, I get this email pretty often from readers who, like,

I just don't even know where to go.

Like, there's so many things to read.

And, you know, I think with time, you're kind of like, well, if I needed to turn over that

stone i could but there's sort of a context you don't need to like master everything and

you know like react stuff it's like yeah it's going to change every couple months like

but you can kind of let go of that anxiety around not knowing anything i think but the first couple

years you feel like you have to keep up with that whereas i mean there you know so many things i

don't know i don't know go around telling everyone it but like i don't pretend otherwise it's just

like oh i needed to like so for me that's a coping mechanism i think after the first couple years

you basically know enough to start and that's that's good enough and then you can figure out

as you're going along and build on that knowledge but that that first couple years that's the tricky

part is like where do i even start here like there's there's so much yeah well uh does this

come out yeah this will come out so not so jango con us is coming up carlton just got back from

JangoCon Europe. And my talk is a 45-minute talk on aligning the Jango puzzle pieces, where I'm

going to try to present the tapestry of Jango as a whole, as a roadmap for people, because I feel

like many people learn it, you know, it's like puzzle pieces, but they're all flipped upside

down. You have no idea where you're going, and somehow they fit together. So to at least say,

here's the map of Jango, and it will take a long time to cover it, but here's kind of the context

i wish i had those first couple years so those are all the pieces of django to like build a

both of how both of how web websites work and then the django part so you know models models

urls templates views admin but also like what are signals middleware like orm query sets you know

so dig dig deeper into things the the geo stuff just give a sense of here is like the entirety

of Django um and you know so here's the fundamentals and then here's all this cool

goodies deployment like there's a I mean deployment is such a big topic um but in Carlton actually I

was thinking of you because you still like multiple settings files right for your deployments

as opposed to one setting file am I allowed to even admit that these days is that like is that

not sorry yeah no I do like I still like multiple settings files because you know what um I see

people jumping through a lot of hoops trying to fit everything into the environment variables only

pattern and i think it's time for the pendulum to start swinging back another way where it's like

you know what if you're fighting with your environment settings or environment favors

trying to put everything into an environment variable so that you can just you know change

your m file or change your folder in order to change your deployment settings maybe you want

to just you know stick that in a separate settings file where it's easy to read and you don't have

this massive amount of machinery

that's needed to be put in place

in the ABU switch environment.

Maybe it's time for the Dependium

to switch back another way.

And then, of course,

we'll end up with multiple settings files

and everybody hard-coding secrets

in the wrong places

and everything.

And we'll swing back

to environment variables

or, you know, something

because apparently

we're not allowed to use

environment variables anymore

because they can be,

I don't know, what.

Adam, what do you think of all this?

Yeah, I was going to say

I tend to do both of those things.

So maybe I'm like the worst of all worlds.

A little bit of one, a little bit of the other.

Yeah, I have multiple settings files for each environment.

And then for anything that's secret, I use an M file to pull the things in.

So that might be even more, you know, messier than both those approaches.

The one thing I do agree is you shouldn't put your secrets in the file itself.

But, you know, sometimes there's various bits and bobs that you need to customize per environment.

it's much more suited to have a separate settings file for than trying to push all of that into

environment variables yeah you don't want to hard code secrets in the in the file itself yes that's

when when the community decided to emphasize not doing that that was a good step forward that

everyone should follow but you know like all these things we end up sort of gravy chaining

gravy but the uh i mean now i sound like an old man but the you know github back in the day when

it first came out you could search for aws secret keys like you could you know you could find

everything and and now i'm sure gitlab is the same you know they they don't let you just search for

that stuff but you could just you know get anything so i think there's a little more guardrails but

um i think these days they might even send you like they might sort of walk up behind you quietly

and do a little cough and get your attention and tell you yeah yeah but i think like pedagogically

to teach to someone new saying one file and then you have your local environment variables and your

production environment variables don't worry about staging don't worry about all this other stuff

is a little bit simpler than a custom command to load different settings files plus all the

platforms as a service require environment variables anyways so if you're using well

what used to be heroku um then uh but yes i agree it's not it's not a canonical thing um

I mean, my pitch for Django is that, you know, that there is a canonical way to solve for this.

I think that would be nice and it would kind of get around some of this conundrum of what you're supposed to do.

With what specifically? Like Django is a canonical way to do these things?

No, no. Like inside a Django, when you, you know, create new project, then it basically sets up your files the way so you have multiple settings files or, you know, the M file and you, you know, and it kind of just like it lets you down, you know, into the pit of success.

And so people just know that this is the way to do this thing, because it is a thing that pops up all the time.

It's the same with, you know, should I deploy my React app with my DRF app?

You know, I see the same sort of questions on Reddit over and over and over again of like, how do I do this thing?

And I think the more that Django can provide, it doesn't have to be super opinionated, but if it can provide some guidance and like, and this is how you want to do this thing that 80% of the people want to do, I think that would be beneficial.

Okay. So I don't normally say things that are on the forward agenda because it just ends up with people going, well, why isn't that ready yet? But this summer, I was very much focusing on async tickets. I've got one more pair of things to try and get into 4.2 on the async front. And then we want to swing around to a proposal to modernize the request object and maybe add JSON parsing to the request object.

So you just go request.data, and if it's a JSON request, you'll get JSON data, whereas if it was a form-encoded request, you'd get the equivalent of post data now, like the .post.

So you get form-encoded data, but either way, you're going to get that back as a nice dictionary.

After that, there is a proposal to actually get around to, okay, what can we look at in terms of making a better story here for people?

It's difficult because every time it comes up, there's massive differences in opinions,

including to the extent that, you know, actually environment variables aren't the way to go

because what you want is a file that you put in place that's read at process launch and

then deleted, and then it's sold in a single thing.

So it's not when the process gets dumped, it's not all leaked in the environment.

You know, this, ah, it's, the trouble is, you know, there's so many opinions in so many

different ways but we're going to sit down okay can we make this can we make the template that

start project template one step up um and it's not an instant process and you know it takes a

while to go through but there are proposals in in place and it's it's coming to the point where

that's bubbling to the top of the backlog to the process so we'll see we'll see anyway that's the

one thing i want to talk to people about at django con us like in the hallway i should go uh research

a little bit the past efforts more but i think that's a big thing i have thoughts yeah right

as long as you write up those opinions that's that's fine yeah okay it needs to be scientific

i need numbers and barge halves just a histogram will do make it up so adam jango unicorn very

good i know andy eyed who builds horse red as he i can't stop him talking about we're hoping to get

him on the show soon he just absolutely raves about it so um you know i think you know people

should go and check that out i want to talk about some of your other projects so can i talk about

the one i'm really excited about which is um minestrone which is a um which is a way of

selecting dom elements from elements from the dom right it's a html sort of search library tell us

about that because i'll tell you why i want to use it it's for simplifying html test cases where

you're testing against rendered html but yeah so um i think you know if you've been in python for a

while you've used beautiful soup if you want to parse html because it's basically the best thing

that you can use it's very lenient and lets you sort of find things in there there are a couple

other libraries that are floating around but it seems like everyone sort of uses beautiful soup

and i use it in all my projects or a lot of my projects and i love it so there's that i find

personally the document documentation is a little hard to read uh just one big long uh you know list

of methods uh and so every time i'm like well how do i find just this elements and so i have to kind

of read through stuff um and the api is sort of if there's a lot there's a lot if you look at all

the um you know attributes and all the classes that are available uh so my basic idea was well

i'm just gonna make a little wrapper library it's gonna it uses beautiful soup underneath the hood

because there's nothing better uh but maybe i can provide just a nicer api for people to do

sort of i'm always looking for solve the 80 because like the last 20 that that's the hard

stuff. And I'm maybe not smart enough to figure that stuff out. But like the 80%, I can definitely

get. So I have nice methods to basically get elements, loop over all of them, look at your

attributes, get the classes. And I tried to do, you know, I tried to make the API as nice as I

possibly could. And that was another thing that I was really trying to sort of get out of this

exercise and this is this is just like unicorn where it's like you know i'm i'm just looking

around and i'm like uh i feel like this could be better like it doesn't have to be this hard

like maybe i can make something and provide it and um you know make things a little bit easier

for people to use the documentation and use the api so that was that was the basic thought about

it okay and um and like you said the basic api is just uh it is uh load in the html and you have a

class and then you can loop over that get all the elements you can grab classes from those elements

and so it's you can search uh using it's basically looks like um like css selectors yeah so that's

across all the html yeah yeah that's that's the point i wanted to get is that you just use a css

selector which you're totally happy with rather than exit what's the x path yeah or whatever

so like in my entire career i've never had success with x path expressions i just couldn't

they just wouldn't go into my brain in the right way so every time i needed to construct one i had

to go and look up the send or look up the query query path syntax whereas css selectors because

you're using them all day, every day,

you know them and you can, you know.

Yeah, it seemed like an easier approach

for people to sort of find things with the CSS selectors.

my my great sort of what i want from this i'm not really writing a scraper and extracting links to

you know crawl the web or any of that stuff because you know if i wanted that there's

frameworks that do scraping for you but what i want is um when you've got html um html you want

to assert a certain equal on the contents right you so you render the template you want to make

sure that the the template you know you're writing a template tag did is it functioning how you want

it to so you want to get the the html and you normally you want to pull it out of a bigger

a bigger page you know what did did the page render with the html i expected so if you can

query that down to a small html element and just match against that rather than is this string

appearing anywhere in this in this html and no it didn't appear and then it prints the entire page

of html and it's like no no no no whereas if you've if you've extracted the the one element

you can just have the html that for that element appear and it's like oh well i see i missed an

attribute or something yeah that's a perfect use case for this um you can use beautiful soup if

you want yes but this might be a little bit easier so yeah yeah so that's why that's that's

that's why i'm excited about minestrone it's worth so it's worth checking out what what other

projects are you yeah i wanted to ask about coltrane i mean you have so many but i mean this

is like sort of like a static site via django which yeah yeah so coltrane um was uh will the um

the author of rich and textual oh it was like mcgune or yeah yeah i didn't want to uh you know

ruin his last name so i don't know how to say it so i'll do i did it i don't know that's just

But he made a tweet a while ago and it was, you know, like, what static site generator should I use?

And it sort of made me start thinking because all the answers are great.

You know, like it's Pelican or Lecter or there's all these Python ones, right?

And there's Hugo and there's Jekyll and there's so many.

But it sort of just like triggered a thought for me of Django does 90% of what all these other things have rebuilt and done.

And maybe Django could do something like these other projects.

And so it was just a prototype.

And I was like, I wonder if I can do this.

So I started by just I use actually Carlton.

think you had a talk at jango con us at some point with a single file and then will i think

you have the repo so this encompasses both of you which is fine i thought you're going to talk

about carlton stuffing like pelican into jango but yeah oh no no no no that was sphinx that's

sphinx oh excuse me excuse me excuse me so i don't know carry on so you use a single file

you use a single file template yeah so i was like oh so i can use this little single file thing and

And I can reduce the complexity of what you need when you have a Django project.

And so I use both those ideas in this.

And basically, it's a Django app, and it looks in a particular folder for Markdown files.

Everything it sees in there, it renders them to HTML and then outputs them to a different folder,

sort of just like every other static site generator.

The other fun thing that I did was there's no databases, right, in a static site.

So I think it's Hugo and in Lector.

There's a couple of options for this, but basically it uses JSON.

So you could have sort of a database where you have data inside of JSON,

And you can pull that out and then shove it into a Django template, and it will get rendered as part of your static site generation.

And that JSON lives alongside the markdown file, is that right?

Yeah, it's in a separate folder, but basically you can basically reach out and interact with it sort of like it was the database is the way that it's set up.

Okay.

Yeah, it was. And the other thing that I did was I used Adam Johnson's, there's like a browser reload library that he has. So when you're working, and you're like, you know, typing up markdown and stuff, it'll automatically reload the contents. So that's a nice little dev experience.

and basically i took django and i tried to make it as simple as possible for an end user to

start up a project um and now it's it doesn't do everything right it's just data content

but it's sort of it's again that 80 20 rule of just like if you just need a blog uh system like

this is a pretty simple way to just start that up and um but it still provides all the power

of Django behind the scenes so you can use Django libraries uh you have Django templates so you have

template tags that you can do things in um most of the other Python static site generators use

Jinja so like it's just a different you know it's a different approach right uh but it was really fun

to work on and so I really like it yeah that's good so if you I mean I think that that point

about being simple so it's literally just a folder of markdowns the important thing right because if

there are there's a whole you can you can start there then if you need a full django site there

are things if you but you still need it static you could use there's a django bakery project

right which takes so that what that does is it sort of reads your url conf and then crawls

the url conf for every to enumerate the urls and that and then writes a stack site and i think

there's a wagtail bakery project if you've got a wagtail set but that's like a lot more machinery

on top and then but then you're still able to just host the output of a folder of static html

files rather than i've got to spin up a django process and have that running all the time and

everything that's entailed on that yeah so i have a i have a site called all django.com

and so it's it's all a static site so i use render.com because heroku is going away sadly

but um render will host your static sites for free so i push to i push a change of markdown

to github render will pick that up it runs a uh it's basically a django management command

in the background and then outputs the static uh html and then it's on the site so it's a nice flow

so that's called trade so go on i was gonna say all django.com i thought that was your

home page that's like your sort of personal that's you know we're all just another thing

that i that i have out there that's all i feel like our question this fall needs to guess needs

to be like what platform hosting service do you like and why because there there's there's quite

a few and i've i've been deep diving on this it sounds like is render the one that currently you

like adam for that's that's what i it's what i've been using the most um when i looked at fly uh it

looked like it was a little harder to start with me i might be wrong about that um but render the

documentation for render uh was really nice for django and it was an easy transition from heroku

heroku was my was my you know standard for ever um and so when i was looking around it seemed like

render was was really the replacement for that but so fly will that will be changing uh i'm

contracted with them to write the the django uh nice docs um so supposed to do that this week

actually um so um because they are lack they don't have a dedicated django docs and so i've

been talking to them and that's they're going to have something both you know an existing site and

a um migrating from heroku but rent you know render render has great stuff too i'm not

making a judgment on platforms but that is a whole fly has and it will be filled shortly

it's interesting when you look at some of the other ecosystems like laravel um i think they

have their own hosting platform that's how they make most of their money yeah yeah and so you

know i know they have a different sort of philosophy in that um in that framework than

django does but it is i i look at that ecosystem a lot to be like and this is a different way to

approach the same problem and maybe there's some learnings there maybe it doesn't really work out

because you know just different different approaches by different you know communities

which is totally fine and i love django i'm not going to move away from it so um but i i agree i

think i have i have a friend who's a larryville developer and he's constantly telling me about

all the things they're doing and um and i you know sitting on the django software foundation board i

will admit sometimes i look longingly at what they do because it's just i think it's taylor

is his name who's like he can just do stuff um and they they make they make basically all their

They make millions of dollars a year on hosting, and then also they have a starter project, like an official starter project.

And then from that, he's able to do all this, you know, give away all this stuff and do new things.

So it is appealing, you know, that it's one less layer of complexity.

On the other hand, it's completely dependent on one person.

But, like, it would be great if Django had Django start project, gave you a site, you know, kind of like their starter projects.

Like, I have Django X.

There's a whole bunch of them.

If there was also an option for like a deployable start, a deployable project, and then click a button, it was up to the vendors, but you could deploy on render, fly, you know, take your pick.

That would be friendlier.

I think the project that I hear what you're saying about Laravel, there's two things.

One there, I think, is that it is one person's project rather than a community-owned project.

I think there's something very, very important that Django has the kind of structure, the community-owned project, the community project that it is.

And I would defend that against the kind of costs that I think if we were to make it into an entity that had a proper revenue stream of its own, then there would be a real danger that the revenue stream gets hijacked.

So, you know, the example, we're not saying this is necessarily right, but in the Apple world, which, you know, part of them follow, all the really long standing people there are decrying the fact that its revenue stream is now services because it's taking away everything that made Apple the company that they loved over the last 30 years.

And I feel the same thing would happen to Django or an analogous thing would happen to Django if Django became a money making enterprise.

So I'll just put that as a sort of something that we can discuss

at DjangoCon sometime over a few bevvies.

But Eric Mathis' Django Simple Deploy project,

it looks like it's just hitting the absolute button here

on being able to just go automate all, deploy, pick your platform.

And okay, he started with Heroku and is now like,

right, I've got to get the other platforms on,

but I think he's got Platform.Shell going.

they were sponsors at Django. He's got fly in almost flying and he's gonna plans to add I've

talked to him quite a bit about this so yes subsequent platforms right and it's it what

looks as well is that it's it would be very relatively easy for um other platform vendors

once they realize that this is the way to instead of relying on Eric to build the integration that

they could build it themselves and be like and submit it as a pull request or as a as a plugin

um and so it may be there with the with the work we were talking previously about improving the

start project that even though we get there a bit slower we might have to get there you know

anyway without needing to um sell the project into a play convert or sell the project but

converting the project into a commercial enterprise so you know i hear every saying i just think

hmm maybe it's not as bad as all that oh well come on i'm i have so much internal experience

i can just you know grass is greener a little bit but i wouldn't trade i wouldn't trade places at

all yep agree so let's have let's let's you've got one more project that well maybe you've got

other projects but we'll come back and ask you any other projects but there's one more project

i want to talk about because it's kind of you know you've got your django django function or

fbv for function-based yes yes that's very interesting tell us about that because obviously

function-based views and class-based views, the eternal, you know, potato versus potato of Django?

Yeah, sure. So Django FPV. So at work, I was making a presentation with my co-worker

about class-based views and function-based views. And, you know, for a long time, I was just like,

CBV is too complicated. I don't want to deal with it. I don't want to understand the inheritance

hierarchy and everything um but i i did this presentation and so i had to sort of dig into

more than i normally can just avoid uh and there there are some nice things about cbvs uh and so

but i i kind of wanted to make a library that provided some of the niceties of class-based

views, but still stay in the function-based view world. Because to me, it's more simple to

understand a request comes in here, and there's a response out here, and I don't have to look into

any mix-ins and figure out, you know, what is happening inside of here with a class-based view.

So for the longest time, there's a library called Django Annoying, which is not the best library

name um but i i would use it all the time and it has it has a bunch of uh decorators and other you

know uh model fields and stuff but uh two of the decorators that i would use there's a i think it

was render two and then there was an ajax one and it basically is just a decorator that you put on

top of a function-based view and you can return a dictionary from it instead of render to response

or HTTP response or whatever.

And it will take that dictionary,

throw it in the context.

Oh, and you specify the template name

inside the decorator function call.

And it sort of cleans up your function-based view,

which I kind of, I like.

And the code, there's not a lot of code.

So I was like, okay, this is all fine.

And then for the AJAX one,

it would do something very similar

or just render JSON response.

And it would take that dictionary and pass it back.

Um, so I use that library for a long time, uh, and, uh, I saw those two functions and

then I started thinking of some other things that I tend to do with class-based views,

like, uh, re redirect view from your URLs or just like a, you know, template view from

your URLs to sort of like some little nice, um, shortcuts basically.

Yes.

And I was like, well, I can do that in a function-based view.

as well it's just i have to write some code to do it so i took that code and i made it into this

library um and it sort of it tries to encapsulate some of those patterns but stay in the function

based view world uh and so could the example there is when you're talking about passing in

it keywords keyword arcs to the as view function so you get your um template view as view and then

you pass in some init keyword what arg so you don't have to get those per request right is that

that's yeah yeah so i so i have the same thing it's just a function um inside of my library

so i kind of that's the other hang on i've got to say because we talked about multiple settings

files earlier that's the other really old school thing that you're not allowed to admit to doing

but which i do all the time is you know a url conflict like my views kind of just sort of in

it and then okay i'll have a views.py for you know more elaborate stuff i mean if it if it works

right like it's not the worst thing in the world um but it's it seems to be sort of people sort of

shaded apart yeah i mean it does it's sort of you know you're like mixing two um responsibilities

right in one thing and so but sure to cut back to going before we move on to cut back before to

htmx um carson gross has done loads of essays on his site which i think um regardless of whether

you use htmx or some other library they're just really good and one of them is about locality of

behavior and one of the advantages of these um kind of html over the wire type things is it keeps

it keeps the behavior in the same place you're not writing css in your javascript file or you're not

writing your business logic over here and you have it's kind of like i'm writing this template and i

just add a few little tags on and all of a sudden it works you spend a lot more time working in the

same file and you don't have to have five files open to to read them and so a lot of these practices

that you know about mixing behaviors that you end up with you know a forms file that's got one form

in it and then a serializers file that's got one serializer in it and a filters file that's got one

filter in it and a view file that's got one view in it and it's like but hang on i could just put

all of those in one file and they'd fit on one screen or maybe i have to scroll down a teeny bit

and it would all be in one place and i wouldn't have to have four files i have in four tabs where

i can't see stuff why can't i just put it in one file and i've been sort of advocating that to

clients um for years and they'd be like they'd sort of look at me as if it was unprofessional

and i didn't have the the tech the sort of the jargon to to give an argument as to why it wasn't

It was, in fact, the opposite of unprofessional.

It was a lesson I'd learned hard over, you know, a decade and more of experience.

And then Carson wrote that essay.

And I was like, that's the locality of behavior is, anyway, sorry.

I just got excited about that character.

It's also a good, I'm remembering, I think I still have it.

I had a blog post on an about page, a Django about page six ways.

basically showing, because I think we all are pretty fluent in Django, right? But a lot of

people don't know how to import. It's like, wait, if I have this file, a forms file, how do I bring

it in? So just being like, okay, let's do an about page six different ways. Let's jam it all into

one file and let's break it out is a really great teaching method, I think. No one ever read that

post, but I was really proud of it when I wrote it. And I keep thinking, I think there's a lot

more here to this i mean your talk carlton i mean part of why i was so excited about your talk was

getting at this idea of just yeah it has guardrails but like you can do whatever you want in django

um but you kind of need to understand the enough of it to feel comfortable doing that right where

it's like yeah we could do it that way we could do it this way versus a beginner is just like

what like one file like that breaks all the laws i've just been taught and you know memorized but

don't understand yeah no i mean yeah yeah like you've got it if you're beginning you could go

with what it does and just follow along until you're 100% sure but sometimes it's easier

literally you know it's only 100 lines total just have the 100 lines next to each other

and you know well it's like learn all the rules then break all the rules that's that's

massively got yeah massively got sidetracked there by the fact that i was so excited that

you were saying you you you wanted to put your template view in your url yes

was there more that was there more to add on that or you summed up the so you were saying before

that you wanted to do the same as being able to instantiate a class-based view um or call the

as view within a keyword arcs um but with function-based view so you but i didn't let

you finish because i oh uh yeah i mean uh so i started with that and then um i added a couple

more just little helper methods like uh there's one that serves a fave icon i think i stole that

from adam johnson's post at some point okay where you can serve like an emoji as your fave icon

instead of setting up an actual image um what else do i have oh i have a middleware so the other

thing that people seem to like uh with class-based views is uh like a having a method explicitly for

get and for post. So you're kind of splitting up those two pieces. And so the way that I tend to

do that now is I have this middleware and it's really simple. It just looks at the method and

then adds a property onto the request object, which is, is post, is get, is head, is, you know,

all the different verbs. And then, so in my function-based view, I can just do if request

dot is get do my get stuff or is post and do my post stuff instead of um request dot method equal

equal you know get which looks a little messy and feels not super dry when you see that over and

over and over again and you so it's just little helper things that i that i added that um seem

like they're useful i think that's a nice example because um i i fun absolutely get the because i'm

a i'm a more or less class-based view man i'll write a function based view from time to time

but more or less i use a class-based view and i normally start it class my my view inherits from

view and then def get um you know self-request args keyword args whatever and um at that point

I look at it as I've got exactly the same as a function based view, which is the request comes in here and I return it from there.

But I've got what I've got is a namespace to break it down.

And of course, it's indented and there's a bit of boilerplate and there's a self argument which gets in the way.

But the sort of advantage is when you get to if get if request is get or if request is post, it's sort of outdented because you've got separate handlers for that.

and it's what's nice about that sort of circle of examples there is to show that it's entirely

equivalent it doesn't matter which way you you do it or which way you like or what you use

because one day's one way is more indented in one type and the other way is more indented in the

other and it's all the same right so what are we arguing about we're arguing about um well i like

blue no i like red which blue says someone else which red says someone we bike show i mean but

it's you know fun to do but i like i like that example um anyway functional based did we mention

luke's um piece yeah so uh we didn't uh but that was a let's mention that quickly then yeah so

django views the right way um it's it's pretty brilliant it's uh it sort of lays out a case for

function-based views um and i actually um you know borrowed some code from that as well for the

redirect view and uh it basically you know you're talking about carson's essay about uh cardinality

like when i read uh luke's uh jenga view the right way it was like this is what i've been thinking

all along and i just cannot like put it into words but like this is so you know like my thought

process when i was reading it so highly recommended super super yeah that's that's an amazing piece i

would say of the top five questions i get from my books you know function base versus class base is

one of them and and people now cite luke's piece to me and i'm like well i agree but um you know

i'm still gonna i think i yeah i do have one question which is um if you if you ignore the

um the inheritance structure of the generic class-based views that provide manjango which

we all agree is very complex and difficult to to master um but if you just take the simple

simple class-based views you know where you're literally declaring them by hand and then you

build and you use the namespace to break your logic up if you need help and methods which is

what i like versus i find functional composition um to be um quite a complicated subject um for

even advanced programmers and it can be difficult to get your head around and difficult to think in

the right ways and this is just literally a question do you think for beginners which

particularly you know you target more will recommending for um function-based views and

decorator approaches and things which i think well are they hard to grok and is it not easier

to teach a class with a namespace with separate bits i don't know that's the question to me or

to adam well lost but i mean what do you think i mean that's my sort of feeling i have thoughts

what do you think adam yeah you're the special guest um is it clear the concern is it clear

what i'm saying because i didn't really yeah i think for new if you're brand new um to programming

and you just want to start maybe the class-based view makes more sense i think a lot of my

you know bias is that i already knew how http worked and so to me i'm like i want a request

and i want a response and i understand that what what to do with those things where it's not so

abstract um and a lot of my what i've realized over the years is that um i have a i have a

reaction because of where i came from with c sharp where everything is a class it has to be

everything is OO to the nth degree, and you have interfaces, and you have, you know, class

hierarchies and things. And so for a long time, I was like, I don't want that. I understand these

functions, and you can compose them. And I, you know, it was a visceral reaction to those things.

That doesn't mean that they're wrong, or they're right. It's just, you know, I think everyone goes

through their own learning experience and what makes the most sense to them and i i sort of love

hate that django has these two ways to render responses because they different people like

each of them and i just think it makes it harder when you're starting but at the end of the day

like you said they're they're equivalent so you know pick your poison as far as i'm yes no i think

to just come back to me the gang of four pattern um for is a method object where you've got a

complicated function and you convert it to a class in order to break the function into separate steps

which are then called from a sort of from the get handler from the main request handler so it's a

it's a method or pattern for um decomposing your logic in anyway that was will you have thoughts

well yeah so i the earlier versions of my books i've mentioned function-based views and shown like

a hello world with it, but said, I want to get you up and going and we're going to backfill.

And so I haven't gone more into it. I get a lot of emails about it. I have been convinced I want

to build at least CRUD with function-based views and do both. But then I want to show like,

build something out that's like a 20 line function-based view and then be like,

this is why generic class-based views exist. And, you know, yeah, you got to do some research,

but like changing one line versus having this custom code that repeats a lot.

i think you know i i go if i can use a generic class-based view i do but as you're learning i

think you need to learn both and so i'm i'm going to add both in more than i currently do but i

still think it's it's sort of like if you're teaching in college class you're like yeah let's

talk about htp and let's do it all fundamental principles but if someone's like i want to build

a website it's it's a question of when do you introduce it for me like that's the tension i

have is like i don't want to just overwhelm everyone so i think that i will for the 4.2

versions have function-based views crud and show a sprinkling of how messy function-based views can

get because you know luke writes them or you know they they can be really nice they can be awful

awful awful awful whereas you know manipulating one or two lines of an existing generic class-based

view i prefer doing i've got an old i've got an old book um called pro jango by marty alchin which

when i was getting up you know when i was upping my skills it was really handy and one he sort of

opens the book with a chapter on python he's like yes yes fundamentally django is just python and so

you need to learn about this it's like decorators and properties and descriptors and yeah like all

these advanced python bits he's like but if you know these then you'll understand how um django

works and if you know that python then you'll understand that you know that these different ways

you know are just are options well this is the problem i find myself i mean i wrote my books

because i didn't like those kind of books but now that i have more experience i understand them more

and i find myself rewriting my books to be like those books so i have to need will is a python

book oh my god oh my god right yes all right adam we're i think we're basically out of time i know

you have a python utils site which is built with unicorn which is kind of cool um we're going to

link to it in the show notes i don't know if you have a quick snippet you need to say or something

you want to plug or call out you want to do or anything anything you'd like to you can follow

me on github or on twitter i don't tweet very much but occasionally i do um and if you want to

keep up to date with i sort of post um updates to what i'm working on and um try to be somewhat

witty on twitter so well i think um django unicorn you're you're looking for some funding right i

mean you have these other screencasts and things if you get more community support is that still

the case yeah i have i have github sponsors uh set up and um i should say i have i think i have

13 right now and so i love everyone who you know has sponsored unicorn it's been awesome i never

thought that anyone would uh sponsor it so that's been great and um it is sort of you know when

you're building something like this it's like you need some intrinsic motivation obviously because

it's like it's a slog i've been working on this for two years so like you don't just you know it's

not it's not uh overnight or whatever um but uh the the extrinsic uh motivation is also kind of

nice of just like yeah people love this and they're using it and they want to support uh open source

and i really appreciate that so adam thank you for coming on the show really interesting thanks

for all the work you're doing the project you're just prolific and super and it's really great to

chat to you and we are django chat.com chat django on twitter and we'll see everyone next time bye