Transcript: LearnDjango.com

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

Hiya, Will.

So Will, you've you've had a you've always still got a site, I guess, Will WSVincent.com.

So I'm

So this is a long-term project that I'm been working on.

So a canonical source of my own stuff on Django that has tutorials, eventually books, courses, videos.

And yeah, we so I I want to talk about what it was like building that and more broadly what it's like building a new site from scratch, sort of the considerations and um because I think there's there's so many choices you have to make, and some some matter and some don't.

Some you just have to decide and don't really have huge architectural implications, and some do.

So we can talk about that.

Um so where to start?

Well, talk

So so the WSVincent.com site, um, it's a Jekyll site, which is a static site generator uh written in Ruby.

And it's really just I've had it for four or five years just as a way to put tutorials and things out there as I was working at um different companies.

And you know, so it has reached a point where it gets um six-figure monthly unique traffic and it's gonna have a couple million people a year.

I mean, that's pretty to me that's pretty high for just a a personal site um that I don't spend too much time on.

And it's just got a a mix of things like Python, JavaScript, book reviews, you know.

So I think I want to have a more you know Django specific place where I can put tutorials that are on Django, I can lead people by the hand, and really the goal is to mimic what I do in person, which is to assess kind of what what someone's level is.

Are they a total beginner, intermediate?

And you know, I I've sort of built a library of uh learning materials, but I want to direct people a little bit better towards them instead of just searching, you know, how how do they find stuff?

Most most people come in through uh Google search and then they leave.

Um, but I know that if they come in and they look at something on Django Rest framework, you know, and there's four or five other things I have that I could tee up or present, or even better, I could do a linear progression where I could say, oh, you're at this stage.

Here's yeah, you know, here's how to go ding ding ding ding and feel like there's some order to the learning, not not this kaleidoscope of Googling around and not knowing what you're doing.

Yes, a bit more Google there.

Oh, another tutorial that was good, like a an experience.

So choose your own adventuring.

Um, it will always be worked on.

Um, but there's enough up there.

There's there's search, there's tutorials, there'll be books, um, and I have it up.

Um, but maybe something to talk about is so the site itself, as I was I've been playing this for a long time, is I gave serious thought to if I should build it in Django or make it a static site.

Because it's essentially a static site, and I like using static site generators.

I use um I've been using Netlify for my hosting, which is really fantastic, that handles everything.

Um SSL, load.

Again, it's you know a couple million page views, and I don't do anything until recently I didn't really have to pay for it either, though they've started adding some pricing there.

Um custom.

And um and also it's even you know, even me with I spend so much time on Django, part of me was like, it's a lot of work to do a Django site.

Do I really want to do a Django site?

Um there's two main reasons.

So one is that I I do do Django and I need and want just an evergreen project that I can perfect and play around with.

Um because I've found myself recently writing these books that I've done a lot of kind of hobby project sites.

Um and there's something a little bit unfulfilling about that.

It's also because I need payments and I I know what the future site will need, and so even though it's a little bit more work up front, I'd I'd rather build what I know I'm gonna need.

And I don't I've I don't see that as over-engineering as opposed to just getting up and running.

And the third, you know, the third is we can get get to this payments.

So payments, if you're payments are really hard right now.

It's uh Stripe and all the other companies, there's what is it, S SLC, there there's the new European law.

So historically you had to have a a dynamic site to do payments um so you could pass the token back and forth.

There are now options where you can do one uh hosted by Stripe or PayPal and do a a webhook in.

But I basically knew I would need it.

Um and I think what I've my current site is actually, I'm really happy.

I've done did all sorts of ver versions of it in over-engineering, but it's really quite basic what I have now, where I have the site itself.

I have so I have tutorials.

So I have essentially a tutorials app with a list view and a detail view.

Same thing for books, I'll have the same thing for courses.

And I the maybe the biggest thing for performance, because I'm I'm now redirecting the blog post for my personal site over, is I have Cloudflare sitting in front as a CDN.

So it's a dynamic site that loads you know instantaneously and it's fast and it doesn't take much.

I don't have to have a big database or anything behind it.

And so the Django view is loading a template, yeah.

Yeah, so rendering it, sending out the right.

So one is it's it's all server-side right now.

Um I certainly had played around and would love to, I'd probably build it with Vue and you know do all these nice things, but that's very much third third phase for me.

Yeah.

We've talked about this.

You don't need to jump to that.

It's a solo project, right?

So you're building it yourself, right?

So you there's a big question about what's possible with one pair of hands.

Yeah.

And the other bit is if you're I just a note, if you're doing redirects, you you need to watch yourself.

You need you don't want to get those wrong.

You want to do a 301 redirect, and we could do a whole episode on that, but you want to be a little bit careful because you're the black box that is SEO, you lose some some of your juice when you do a redirect, um, but you could lose like all of it, or you could really lose stuff.

So it is sort of a long-term play.

Like my traffic has gone down a bit because now there's this new site, and even though I'm redirecting, so I sort of know that as part of you know a project where you start it and just have all these things, and then you go more specific.

And there's a way, so within Jekyll, there's a there's a way to do it properly.

And actually, intra interest somewhat interesting.

Netlify just notified me that I have two weeks to change because how they handle redirects is going to be muffed up, and so I'm like, great, thanks, Netlify.

That's just what I need, like something important and technical to deal with.

But anyways, so it's built in, um, it's built in Django, and you know, the considerations when you start a project from scratch, I put a lot of thought into, you know, again, it's it's it's sort of like contemplation when are you over-engineering when you're in when are you not, thinking about the authentication in users.

You and I had a discussion about this, I think we put on the forum of okay, well, how how do I want to handle authentication?

Because I do want to have it, because I'll need that for people who log in and pay.

And you know, if you're going to offer a learning path, and you know, it's all right doing that statically, but if there can be little ticks that appear for an individual user and all of that kind of stuff, it yeah, I guess you could do it with JavaScript, but really you want that to be back-end driven.

Right.

I mean, there's this whole, there's a whole, it's actually not really Django specific idea uh thoughts around do you require a login, how much do you gate, how much do you not?

For now, I I have a mailing list at the bottom, so a newsletter, because you know, some people want to get updated whenever there's a new article or once a month, and some people don't, but they still want to be in the system.

So that's actually something I'm still going that's going back and forth a bit on um for how do you handle that, right?

There's sort of two streams of thought.

One is you you put you do this drip campaign thing where people come in and you basically hit them with an automated sequence until they unsubscribe or s or stay, you know, basically until they buy something or leave.

And the other is maybe more like like a West Boss approach where you require the email up front and then you only email like when you have a new course once or twice a year.

Yeah.

Most people would recommend the former, but I feel like there's something to the latter, especially if you're an individual where it's it's you, it's not a company.

Yeah.

Like, you know, and these these nurture sequences uh I don't know, that it it seems like everyone's got a subscription you can sign up to, and you get so many emails, and the the value of them isn't always that, you know, this is a nurture sequence that really is giving me something.

So you and I, Carlton, we're power users, and we I personally don't like drip sequences.

I I I find it off-putting.

Um, but um hard to say.

Anyways, for now, I'm not barraging people, but I do have a login thing.

Um, and to get back on that topic, one of the um maybe you can talk about so there's I like doing this idea of you I use Django all auth, um, which is a package I'm very fond of.

And I like having email and password um actually not using username.

And then the last bit of that is I have to wire up my email um service, which I use SendGrid for that, which is pretty straightforward.

I have some tutorials on that.

But you have this nice approach that you like to use, right?

So uh I'm just really old fashioned.

But like it's like you know the username for me is like something that can appear on the site, you know.

So if you've got a per a profile page, it's like GitHub slash will.

Yeah, like GitHub, right?

So that kind of publicly exposable user, unique user identifier.

Like that that's your username, that's my username, that's so-and-so's username.

I don't I like to use email for login because people like that.

And I what um all auth gives you is this nice email, uh, email ability to handle multiple emails, and you can verify them individually, and you can mark one as primary, and it allows you to it helps you to do the login with the emails, and it it's got some good stuff going on with it, all auth.

And then the user ID is like you know, the the actual ID that's in the database, but that never goes public.

So I never put that in a URL or I never put that anywhere.

That's that's that's that's the the the internal unique identifier which picks out the user, but that's not their username, right?

Yeah, well an email, you know, I can have multiple emails per account and

I mean that's something I I so for my site it it doesn't really you don't need a public username because it's you you log in and you have access to courses, but it's just a

profile page.

Yeah.

Um and indeed I built a whole you know version kind of the way you had described, and then I really thought about I was like, I don't you don't ever need that for what I'm building, which is just basically an element.

And when I say uh when you say advocating, it's it's what I like to use in sites that I build for for these reasons.

You know, is there an extra directory?

Like there's a whole bunch of those.

Um and side note, my book Django for Professionals, I walk through a lot of these steps of showing one way and talk about the trade-offs for how to do all this.

So um if I appear tired and garbled in this, which I am, um, that book is a resource.

But what else?

Models, right?

So if you are are we okay switching?

Yeah, switch gears.

So models, there's um let's take the tutorials.

Um actually I probably should pull up what I even have in the models.

Okay, so so models.

So I mean I think it might be interesting to talk about the model I have for tutorials where and this and again, this pattern repeats itself for in many projects.

So I have an author um which uses get user model, um, so that refers to who writes it.

That's you.

Well, it's me, it's me.

And I guess that's potent perhaps that's slight over engineering because it

I I that's a whole separate uh thing, but I have the capability of doing it if I want to.

Um and I have the title and the description, um, and I've added the slug.

I've got a whole Django slug tutorial because I want to use slugs, and again, because it's just me, I don't worry about collisions there.

If I was building um a Twitter clone or I don't know, a Twitter clone or something, I would, and that's actually a great example of if you have a username, you don't have to worry about these collisions as much.

Like if you're building a blog platform, if it's blog.com slash Carlton slash, you know, you don't have to worry about you and I writing the same hello world um

Like and you might have a an extra path segment for a date, which I know isn't fashionable, but if it's actually, you know, if it's a blog, you might have a date, which it helps to you keep it unique, so it'd be unique for that date, or unique for that year, or unique for that month, or whatever.

Or you can have an extra little slug component.

I'm sure we talked about this.

identifier, which is unique.

Um I don't use hash ID in this.

I was gonna say I do in the Django Professionals book, one of the chapters, I walk through ID, UUID, um hash ID, you know, kind of because that's tricky for beginners to understand how you how you implement that.

So you can make sure the

And actually, um this is in my my Django slug tutorial, which you can find in the search thing on learn Django.com.

I use the admin section because for now I'm I'm putting it in the admin, so it auto-populates the the slug, so it saves me a step of you know, if it's hello world, it'll automatically lowercase it and be hello dash world.

Um I'll link to that

So you're using you using the admin, you've got super win there, because you've got a UI which is perfectly acceptable, right?

Yeah, yeah.

Exactly.

Um the last bit uh is two things.

One is uh I so I add a created at and an updated at field.

Um so the the created at is uh auto now add, the uh uh updated at is auto now.

Um a nice way to do this actually that um I wasn't aware of that Jeff Triplett showed me is if you use Django extensions, there's uh one of the Swiss Army features in there will automatically add these updated at.

But but basically any almost any model that's gonna have users update, you want to add a created at updated at just as a you're gonna want it later situation.

Yeah.

And then the last bit is I have a um is live Boolean field.

So I can do I can do drafts and you know decide if something's flagged or not.

Um Yeah.

And that's that's really it.

I mean, I also, you know, I could do an underscore string method, uh, you know, get absolute URL for the detail view, and and that's kind of it.

I've I've made more complicated versions of it, but it really doesn't have to be much more complicated than that.

Um and that's the same approach I have for and

You can always add a field, right?

The the Django's migration framework is super and it lets you evolve your model.

Whereas you sit there, spend three months planning all the fields and all the possible interactions, and you've got this model which has got 42 fields, and you you only ever build the software for the first four fields because yeah, you never you never get to that.

So just drop all that time and just write the four fields and work with those.

Oh, I need a new field, fine.

Make migration.

I'm definitely going that route of I can always add stuff in, and migrations are fantastic.

I guess two other big buckets to talk about.

Um so one is deployment.

I mean and again, because I have Cloudflare sitting in front of it as a CDN, that absorbs the bulk of it and it makes it fast, and I'm not getting the dad, you know, the um the server is barely being hit because everything is cached.

Because you've said CDN a couple of times, but for CDM um when someone says that that brings to mind like images and static files.

Yes.

Okay.

I think it's I think it's every every once at once a day.

So this is something I will go a lot deeper on when I have where I'll it'll be section or page specific.

But for now, what I want to do is have it, and actually I should double check.

Um so when I whenever I do an update, it refreshes the cache um automatically.

But I'm I'm just doing very broad strokes.

Um, you know, Django on its own.

I mean, there's nothing, you know, if you know when I start having when you're logged in, you see things that you've checked and progress that you've made, you know, that's when I will fine-tune that.

Um and there, and I'm actually not quite sure exactly how I will do that.

You know, so Django comes with built-in caching framework that you can use.

I have a tutorial on that.

But then also Cloudflare lets you do it at sort of the Cloudflare level.

And I'll probably do it within Cloudflare, uh Cloudflare more than Django, but I haven't done that for real yet.

So right now that's a big broad stream.

So say you're so say you're rendering Markdown, right?

Which is an expensive process.

So say you're rendering markdown, which is an expensive process.

You want that rendering bit to be done.

So you could at least the rendered markdown fragment, you would cache that in Django.

Yeah.

So that that that if you know, if if multiple requests are made for the page, then it just it doesn't have to re-render the markdown, as which is the expensive bit.

Whereas rendering the template, ah, that's pretty quick.

You know, if if if the markdown is already converted to HTML, injecting into the template and sending the template along, you know, that's not a slow process.

Um and in the uh tutorial I wrote around it, I I showed, I talk a little bit about some of those options.

And again, it's a little different to where this is just me now, so I don't have to deal with it's not a public uh you know blogging platform or something like Medium where these things matter a lot more.

For now, it's just me and the performance stuff I can just toss behind the ship.

So you might use something like Bleach or

Um and that is actually something where you you know how you configure your static files and stuff when you're dealing with um if you're using white noise, which you probably are for uh serving static things, it will not do user uploaded uh things.

You have to use Django storages.

Um again, apologies, I'm super sleep deprived, but um there's

Um so that that I had a little small little bug on that, and I was like, what's going on here?

And that's what it was.

Django storages are um white noise will not do that.

You have to use Django storages um just to get around that, and that's security thing.

Um so some extras.

So this is more the list of when you break down like just a basic Django site, there's so many things you can and should add to it.

So, you know, search is one.

So I have basic search set up where I'm I have a tutorial on this where it's just there's nothing fancy.

I'm not using Postgres built-in search, even though I'm using Postgres, so I will add that later on.

But that's sort of a nice feature to add.

Um, sitemaps, sitemaps are so that's there'll be like a slash sitemap.xml, which you can point to Google or whomever and say, hey, here's a listing of my site, and you can add meta information around like how often to update it.

That's a something you should do.

There are some gotchas on that.

Um if you have a very large site, so I had this on a project, a Django project a couple years ago, where I had 200,000 things in the database.

Um the site maps will only do, I think it's 50,000.

You can't just have a single canonical site map.

You can break it into sections, um, and that's something you want to do.

Um a little tricky there.

Um syndication for

I think I found that generating them was so slow on my server and such a hit that I made it 5,000.

Right.

But you know, that could be you could change that a number of ways, but just be aware that um there is a limit and you wanna you wanna have site maps.

Um syndication framework.

So that's if you want to have like a RSS feed, uh Django also comes with built-in support for that, but you need to add that.

That's something else you should add, even if you think people don't use that, a lot of people still use that, and you can point other things to it.

Um, especially if you're doing, you know, like a blog kind of site uh as I am.

Whereas if you didn't, you've got to, well, you know, I've got to write a little um agent that runs on the server and it checks every so often if there's an update.

Or yeah, no, don't do any of that.

Just create an RSS feed and then use you know Power Automate or Zapier

Obviously, I'm using Google Analytics.

I'd like to use something else long term, but you know, analytics are good.

I'm using Uptime Robot to um just check if uh the site goes down.

Um there is so Django has a translation um a fantastic translation framework that comes with it.

Because this is just me, I'm probably not gonna use that.

What I found actually, and this is uh another reason why I want to move from PDFs to online, is that readers you know can use the built-in browser translations, which is very powerful and very good for my for my books.

So I'm not gonna be using that, but a lot of larger projects you would want to use that.

And what else?

There's just there's so many little things, right?

Even though I build these, I build sites all the time.

It's been a little while since I like fully built one out, and there's just so many small steps that um I find myself kind of, you know, it's like I have a list of like the first 10 steps, but then to get to a step 100, uh, you know, I I kind of even I meander, yeah, right?

Even though I've written it.

But you can't you can't get it.

Like you have this, you sit down with a piece of paper and a you know, glass of wine or whatever, and you're coming up with your your plan for your site, and it's gonna have all these features, and this bit will be written in React, and you know, all of this stuff goes on.

And the reality is that you know, getting just getting the logins right so that it's 100%, and getting it so that when people sign up for the newsletter, like they actually get the newsletter and they only get one and they don't, you know, they can control that preference and all the unsubscribed links are in the right places, and that takes ages.

And then put it in your tutorial so that they they they come up nicely and that people can, you know, view them right or get an update from their RSS feed or whatever.

It just takes ages to get this.

No, you never get there.

So I'm I'm a little more careful with this than I would be if I was just throwing it on the wall and see if it would stick.

Um but it does take a lot of time.

Um, you know, of course, I've changing the admin, it's not at slash admin.

That's the best practice we've talked about.

Um and I'm using Docker throughout, um, which that's a separate discussion, but I find that I know how to use it, it works for me.

I'm just deploying the container up there.

That's like the that's the that's deployment in the

Um, it's some what are some other cool things?

Um so for for my continuous uh integration, I'm using GitHub Actions, um, which actually works pretty well.

So I don't have like a server uh staging set up right now.

I am again it's that tension between getting stuff up there and adding all the things that I know I probably will at some point, but again, because it's because it's just me, I you know, I'm it's different than a team production site.

Yeah, yeah.

If I need to, I can always, you know, I can revert a commit, I can roll back something.

Um so I'm a little more fast and loose there than I would be if the this was a team of people.

Like, um, you know, it's like uh uh using Kubernetes.

Well, great.

If you're a big team and you need 500 engineers and they all need to work on separate projects and they need to be able to do that, fine, brilliant.

But if you're a two-man man or two-person band, what on earth are you using Kubernetes?

Well, I mean, you might have to be able to do that.

It's like that's like using Kubernetes.

Yeah.

Um so I will and then and then so and then the last bit is payments.

So payments is a total it's unbelievably messed up how hard it is for a small business to do because you have taxes, you have all the you know all these requirements that have come in.

I would love to just use a service.

I mean, basically, like so for me as a small business content creator, I just want credit card and PayPal.

PayPal is important because a lot of people use that.

Um PayPal is very challenging to work with.

You know, Stripe obviously doesn't have PayPal support, so then you go, okay, what am I gonna use?

There's Charge B, there's um Braintree, there's a new one, um Paddle, uh, I believe it's called that um Dan Pater at RealPython's using that uh handles in theory all the tax stuff for you, but they are opaque on their pricing.

And with so much of this, you know, I've tried to talk to lawyers and other people who run platforms.

A lot of these rules around Nexus, so do I have to cleate uh collect state tax, do I have to collect you know, VAT, even though I'm based in the states, they don't really apply until you are at a larger scale than I am, you know, something like seven figures.

But yet so basically you I find that I even though I want to and I won't put time in to do this properly, there is no way to do it properly because the rules are being changed.

It's completely onerous for small business to do, there's no all-in-one solution.

But if someone were to have, you know, credit card and PayPal and handle the taxes, there's services like tax jar and stuff that you can plug in, but um it's a real cost.

And this is the other content creators I I talk to, we all just go, Oh my god, this is so hard to do.

Um and it's even harder for subscriptions.

That part of the new rules is around you have to you can't just indefinitely have someone be subscribed.

Um, I'm gonna be doing um not I'm not gonna be doing subscriptions, I'm gonna be doing courses, but it's still a lot of work.

And honestly, it's something that's post paternity leave, hopefully post coronavirus that I integrate all that.

I remember, you know, 15 years ago trying to it was always iframes and you know it was just horrendous.

And then Stripe came along and it was a lot it was a lot better.

Yeah, but it's still not but it's

Um and and PayPal is still challenging.

And you know, and that's the bit too where I like I really don't want to get that part wrong, right?

Like, so I have testing, but um obviously I really don't want to get payments wrong for a lot of reasons.

So for now, um I'm still

But look and testing payments is just so obviously hard to there's no they they don't offer any way of like for instance Stripe with their Off Connect platform or whatever there's no way of testing it short of manually creating an account and you know stepping through it in the browser and but to know that it worked, but that's not a sustainable testing program that uh process.

It's really um yeah, challenging.

Yeah, challenging.

So that's the state of things.

Um uh the site um and the design of the site is something that I've kind of punted on.

I mean I love doing design, um, but it's a bit of a time trap for me.

I'm just using Bootstrap.

It looks fine.

At some point, I will eagerly look forward to devoting time to making it look great, but um, I'm not letting that get away.

Something like that.

Yeah.

What else?

Is there anything is there anything else?

Uh you know, and so video, I'll probably be doing video at some point.

Um, because I have things structured, the way a lot of people do this is you can use for private video, you can use you could use YouTube, but then it has ads.

You can use a lot of people use Vimeo or they use Wistia.

Um Wistia is a bit better, but it's um quite expensive.

And what a lot of people do, which I'll probably do, is you you use YouTube for the free stuff, so you don't have to handle the bandwidth.

Yeah.

And then you use uh something else for the you know behind the paywall version.

Um but we'll do episodes as I build these things out, it'd be interesting to talk about.

Um but the the basic site, you know, if I knew what I knew now, I mean it's not that much code.

Um it's really a couple apps, it's the authentication.

I'm using Cloudflare.

Um, you know, payments will be a big struggle.

I've got site maps and syndication, but it's it's simpler than I thought it would be actually.

And partly that's because other people who've built sites in Django on this are doing things like they're using Redis and they're like sharding and all these things that I don't quite understand.

To me, you know, it's like this running joke I have with my friends.

I'm like, you're over engineering that

And I'm and I'm actually I'm I'm really excited about having a project where I can do what I want with it.

So I can have fantastic test coverage, I can play around with new things.

You know, I've sort of realized that even though I could have had this up a lot quicker, doing different ways, um, it's worth having a personal playground and you know, it feels good, right?

I mean that's the challenge too for developers.

If you're working on a production product, you're just constantly given, you know, agile sprint, sprint, sprint, sprint.

And sometimes I want to write tests, or sometimes I want to play around with something, and I, you know, because of because of where I'm at in my with with the work, you know, if I learn something I can teach it and part of that I can monetize, so it I sort of self-justifies or justifies taking the time to spend extra time on things.

Um I'm I'm excited about that.

Yeah, it sounds very exciting.

When it's ready, we'll talk about it, but

It's no rush.

Um I'm happy to you know, we'll do further episodes on stuff, um, get feedback.

Yeah, there's more to be said about you know, this this prototype first production is just for everyone, it's it's a it's a big jump and you just have to kind of make some decisions on how you do it.

And the important thing is not to waste six months making it perfect locally and never getting it up.

You just gotta

Release early, release often, you know, get it out there and just incrementally improve.

And like you like the minimum viable product for Learn Django is that you're putting tutorials up there, uh they're readable, you could subscribe to them, use the newsletter.

Brilliant.

Get it up.

There's no reason for it not to be up.

Episodes on Django.

Um, thanks everyone for listening.

We're at Chat Django uh on Twitter.

Bye bye.