Ruined by Django¶
This the prose that accompanied a live coding presentation at Common Code
SCENE 1 - THE INTRO¶
FADE IN:
HUFF BAGELRY - MENTONE (BLACK & WHITE)
So it's Saturday morning - a few hours before the grand final at Huff in Menton and I still don't have a talk for Thursday.
You only have yourself to blame Jon, Bec has given you at least 2 months notice
I'm waiting for my breakfast. I'm thinking back to the last few talks
We have had reimplementing React components in Rust
Looked at how our choice of language affects the way we solve problems
Seen collaborative music application and shared in the pain of an industry who routinely takes away our toys.
And the game of Gif (Jif!) has reach a whole new levels.
How do I even compete?
Stick your guns Jon, talk about what you know.
They are going to want to hear more than my normal mid-tea making spiel.
Ah, but this time they have no choice - they can't run away faining so called work...
I'll need to think of a clever hook, something to lure them in
I'll flip the whole thing on it's head and tell them how Django has ruined me as a developer.
It was about this time my bagel arrived, and thus my slides got no further.
SCENE 2 - THE SWITCH¶
CUT TO COMMON CODE - ABBOTSFORD
JON SITS NEAR MOTIONLESS IN FRONT OF THE WHOLE COMPANY
HE HAS TEA
So here we are, I hope you enjoyed the presentation.
A POLITE ROUND OF GUFFAWS, NO ONE IS THAT IMPRESSED WITH THE JOKE JON
I did have a couple of other ideas but nothing that I thought would make a great presentation
At least not yet.
Perhaps worth sharing?
But how?
I have it!
I'll demonstrate how Django has ruined me by building a presentation system
I'll use the half finished content of my other talk ideas as example data!
SCENE 3 - START PROJECT¶
JON FAFFS WITH HIS LAPTOP IN THE VAIN ATTEMPT TO SWITCH TO HIS CODE EDITOR SMOOTHLY
I'm going to spare you the drudgery of setting up python and a virtual environment.
The first thing we need to do is install Django
$ pip install Django
And then on to create a project
What to call it?
Vowels aren't cool any more so lets just call it PRSNT without any
$ django-admin startproject prsnt
You can see this has magically created the framework of out project
Little known fact but Django's startproject command can be used with alternative project templates.
We can actually start the project server and look at it now.
IN PRSNT FOLDER
$ ./manage runserver
JON SHOWS THEM THE SITE IN THE BROWSER
OPENS A SECOND TERMINAL LEAVING THE SERVER RUNNING
SCENE 4 - APPS & MODELS¶
Not so impressive so far.
We start with the models, we always start with the models.
Django is all about the models
But first we need somewhere to put them.
For this there is apps
Most frameworks tend to split code into sections based on their function
So a models package, a views package and so on.
Django flips it around splits by business intent, or to some extent domain
$ ./manage.py startapp content
That created a new package for us with lots of stuff in it
we have a models.py for storing our model definitions
We have a views.py for holding our views
and a few others I will come to
But first we need a model to hold our presentation
A SLIDE model
JON WRITES THE SIMPLE SLIDE MODEL
SCENE 5 - RELATIONAL SUPERPOWERS¶
now that is done we tell Django where the app is by adding it to the settings
Django is quite tied to the relational database model. This is a superpower
$ ./manage.py makemigrations
Django is able to generate migrations for the database so I don't have to
The migrations are not just SQL
They are reallY just plain old python.
The job of creating the SQL is left to Django
So the same set of migrations can be used no mater what database system you settle on.
REMINDER TO JUST USE POSTGRES
The migrations system is pretty smart.
It can tell when you add and remove fields
In many cases it can tell if you change the name of fields
$ ./manage.py migrate
Whoa!
Wait a sec, that was a whole bunch more then I expected?!
Django has a whole built in user and permissions system.
Those additional migrations are modely about that...
and the next thing I want to show.
The Admin
SCENE 6 - THE ADMIN¶
OPENS ADMIN.PY AND REGISTERS THE SLIDE MODEL
VISITS THE ADMIN URL IN THE BROWSER
Access to the admin is protected
We need to create a user
But we haven't implemented any user management yet
$ ./manage.py createsuperuser
JON LOGS IN AND SHOWS THE ADMIN INTERFACE
GOES TO THE SLIDES MODEL AND ADDS A COUPLE
The list display looks pretty useless like this
So lets fix that up
ADDS A _STR_ METHOD TO THE MODEL
Much better
We could get really fancy adding a bunch of columns, definining filters and so on.
But instead I think I should move on
SCENE 7 - THE VIEW¶
Our visitors need to be able to see our presentation
For that we need a view
OPENS VIEWS.PY AND ADD A GENERIC LIST VIEWS
And a way to route to that view
OPENS URLS.PY AND ADDS PATH
SHOWS NEW PAGE - TEMPLATE ERROR!
So we need to add a template for this
It even helpfully tells us what the templates name should be
CREATES A TEMPLATES DIRECTORY
ADDS A CONTENT FOLDER AND SLIDE_LIST.HTML INSIDE IT
ADDS THE TEMPLATE DIRECTORY TO SETTINGS.PY
RELOADS PAGE
Now we can see the slides
SCENE 8 - PAGINATE THE WORLD¶
Seeing them all at once doesn't make much sense so lets only show one at a time.
OPENS VIEWS.PY AGAIN
ADDS PAGINATE_BY PROPERTY
UPDATES TEMPLATE
REFRESHES PAGE
It seems to me that that pagination block is probably going to be reused
Lets split it out.
MAKES A PARTIALS FOLDER IN TEMPLATES
ADDS A PAGINATION.HTML
INCLUDES THE PARTIAL IN THE LIST TEMPLATE
REFRESHES
NO CHANGE IS OBSERVED
You can also inherit from template, overiding named blocks of content.
Great for avoiding repeating yourself, for componentising your frontend
SCENE 9 - GOT MARKDOWN?¶
Now the actual content of the slides is a bit dull
Lets make them a little slicker by allowing markdown
$ pip install pymarkdown
ADDS RENDERED_CONTENT METHOD TO SLIDES MODEL
UPDATES TEMPLATE
REFRESHES
Huh, it is rendering the actual html, weird
Django protects you from nefarious intent by escaping the data it gets from the view.
But in this case we want it to leave the content along.
So we add the SAFE filter
ADDS THE SAFE FILTER TO THE TEMPLATE
REFRESHES
And it renders properly now!
SCENE 9 - APIs EAT THE WORLD¶
"But Jon", I here you say
"ain't no one doing server side rendering these days you dinosaur"
Sadly this is often true, but Django has your back here to.
Lets make and API!
$ ./manage.py startapp api
$ pip install djangorestframework
JON ADDS REST_FRAMEWORK AND API TO THE INSTALLED APPS
CREATES A MODEL SERIALIZER
ADDS A VIEWSET
ADDS A ROUTER TO THE URLS.PY AND INCLUDES IS UNDER /API
Now we can just go to the base url for our API We get a browseable API we can explore.
And while this is a REST interface, similar plugins exist for GraphQL
SCENE 10 - THAT A WRAP¶
I dare say we have pretty much run out of time by now.
So I want to sum up by saying that Django has ruined me as a developer.
It has elevated my expectation to such a level that nothing else comes close
Nothing else gets me up and running so quickly
Has such a range of well thought out functionality built in
Or such a large range of bespoke plugin for everything under the sun
There are so many other topics and avenues I could have gone down
- Testing support
- Form building and validation
- Integrated handling of uploaded media
- The depth and flexibility of the generic class based views
- Even the forthcoming support for asynchronous execution
All built in features
But I know we all have other stuff we need to get on with
And while I have gushed about Django a whole bunch
I don't want you to think it is perfect
It's not
Even I don't think that
It has flaws, it has quirks,
It, like all other frameworks, has a blinkered view of the world.
It won't fit every situation
and trying to make it do so is often a mistake
But for me, and for the majority of the work we do here I do think it is a perfect fit
If there is one take away I want to have learnt today
It is that
Django just gets the job done faster without sacrifing too much to do so
FADES TO BLACK
FIN - FOR REALSIES