Transcript: Django Forum - Ken Whitesell

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome, Ken.

Welcome.

Thank you.

So maybe we could start with how did you get into programming and then we'll work our way into how you became so uh involved in the Django world.

Um we're trying to keep this at under an hour, right?

Um let's try to give the condensed version here.

Um actually got started with programming uh with a programmable calculator, uh an old uh TISR 52 uh from back in the late 70s.

Um the time that had the little magnetic card strips that you would feed through the calculator that would store the programs uh and the thermal printers that you could attach to it.

Uh had a friend of mine in high school who had one of those, and we just spent hours uh mucking around with that, writing little programs.

Really was my introduction, it's what gave me the bug.

And then from there, uh everything just kind of mushroomed.

My senior year of high school, we had moved, and I moved to a high school that actually had access to a mini computer at the time, an old HP 2000, yeah, running the old timeshare basic.

Uh, and that was uh that was my first actual education in it.

And I I I caught the bug immediately.

I I knew right then and there within like my first week of that class that I knew what I was gonna do for the rest of my life.

So that's that that that trumps the the usual question because we're always like, so did you learn at university?

Did you you know, and you're like, no, I learned at high school.

Uh for for me, because I'm a little bit younger, it was sort of the web.

The web came around when I was in high school.

Um yeah, middle school, high school.

So that was the first like tangible using technology.

Oh, what is this thing?

Kind of um that got me and a lot of people involved.

Um, of course, I had a TI eighty two, eighty three, which is sort of the, you know, a couple a little bit later.

And I remember you could play Tetris on that, you know, Mario Brothers.

Um, I don't think I actually programmed it.

I thought it was programming, it was more like copying things from friends, but it felt like programming.

You look at somebody else's example and you decide to tweak it, modify it, and then you end up with something that's, you know, kind of yours and kind of what you drew from.

Yeah, no, exactly.

Um, so it's interesting to see what it is for people, whether it's a calculator or games or the web or something else.

There you have to kind of have that first, right?

Like, because otherwise programming for the sake of programming doesn't make any sense unless you have a goal in mind.

Yeah.

I missed uh the registration period for college, actually did not get into college at that point, and so I decided to join the Air Force.

Uh joined the Air Force to see the world, spent three years in Bilexi, Mississippi, and three years in Washington, DC.

That's two parts of the world.

Yeah, yeah.

So yeah,

So I think the first time Python came in the scene for you was was 99, I think, which is very early on in Python's sort of in Python's history.

How did you how did it pop up in your radar?

We were migrating some servers from Windows NT to Linux.

Uh we were uh using a very early distro, don't even remember which one now.

Um, and we had a need for a process that would monitor a directory to see when files showed up.

So there would be people who would FTP files to this box, and the process needed to detect the changes in the directory and then process the files.

And I found a snippet out on the internet, wasn't all that big, 20, 25 lines of Python that would monitor the directory and then do something with it, and that something was what we needed to do with it.

Uh, you know, run run another script as a result of it.

And I first took a look at Python, and it's like, okay, this is different than anything I've ever seen before.

The uh syntax significant white space, and and uh it was certainly more verbose than the other languages of of the time that I had worked with other than COBOL.

Uh and it it just really appealed to me, actually.

Uh I won't say I ever really had a fondness for COBOL, but I certainly had enough proficiency with it that verbose languages were not a problem per se.

Uh but something just with the the requirement that the code be laid out in a structured way, unlike C, you know, with all the the hidden gotchas with the uh braces missing semicolons, whatnot, it it really resonated that that the layout of the language just helped make the structure of the program so much clearer than trying to pair up braces or parents or

whatever.

Because you said 25 lines of Python, it's kind of like the the archetypal situation is I need to script something up.

I do it in Python, oh it's 25 lines, it's always 25 lines, it doesn't matter what you're doing.

Uh uh compared to say the other language you mentioned was C, it's like it's gonna take you loads more than 25 lines to do it in C.

Like, so how was the abstraction level compared to what else you had available?

So the language uh is what attracted me at first, and then I started looking at the standard log and looking at you know, seeing the comments about being batteries included, and just starting to read through the library documentation, and it's like, wow, you know, there's a lot here.

It's not okay, perhaps a bit pedantic of me.

It's not so much that the abstractions were at a higher level, but that the libraries were so comprehensive that I didn't need to go hunting for a library to do X or to you know find a code snippet somewhere else that did X.

Is that okay, there's a function for that.

And I just call this function and it's there.

Yeah.

Well, and that was I I had to look it up.

I think that was around Python Python was 1.5 or so, so it was

Um, but when I was teaching college students, I would who didn't know much programming at the time, I would just lay out, I'd say, here's hello world, and you know, Java, C, Python.

Just like you don't know anything about programming.

Which one do you think is easier to use?

Right?

I mean you just look at it and you know, right?

Oh yeah, yeah.

So it's sort of an interesting, you know, whatever level of programmability you can just look at it and say, Oh, you know, yeah, white space is very helpful.

Oh, it's nice that something is shorter, and also that if I want to print something, it's called print, it's not 13 lines of gobbledygook.

And what were they?

Because you know, later on it was Django and requests and you know these other big stalwarts of the ecosystem.

But what about then?

My needs at that time, I mean, at that point in time, let's see, 99.

Yeah, 99, I was still uh I uh was still doing a lot of low-level work with server server management.

The company that I worked for at the time uh was an insurance firm, and they had 300 offices scattered around the United States.

And so what we were doing is that we had this rather intricate dial-up system that we would distribute updates from the home office, we would dial to their local network, uh send files to them, and that was the purpose of this code is that we would send data updates to them, whether they be rate changes or customer updates, whatever, we'd send these update files out to them, and then the system would receive the

files, unzip them, and add them to the local copy of the database.

Because at that time there was no wide area network that we could afford to implement through these 300 offices.

Broadband internet was still a dream in the future.

Everything was dial-up.

And so it was do the processing in the home office, distribute the files overnight.

They come in in the morning and they've got refreshed data.

That's that's you know, they're still doing that with iPhones now.

You know, I get a little message.

That's cool, though.

That's really cool.

So it's sort of the the tools have changed a little bit, but the problem is still there about you know, collating all this health insurance data.

You know, how do you how do you keep 300 computers in sync that aren't directly connected to any sort of uh internet or direct networking?

It's an interesting problem.

Yeah.

So Django, speaking of the web, when did when did that emerge for you?

It was PyCon 2005, I believe it was.

In in my mind, I've dubbed that the PyCon of Web Frameworks, because that was like the time period, the 2004-2005 time period, where the saying was, you know, you haven't worked in Python until you've at least written one web framework.

And there were dozens of them floating around, some better than others, you know, and and a number of them just kind of faded off rather quickly.

But all of a sudden, out of the blue, there's this new one that poked its head up, said, Hi, I'm here, Django.

And I remember at the time Guido making some comment, I don't know whether it was a keynote or just a talk or even possibly just an offhand remark, that he was expressed an opinion, personal opinion, that, you know, he felt that there was going to need to be some sort of shakedown of this plethora of web frameworks.

You know, that there really doesn't need to be 10 different web frameworks all receiving a lot of attention.

And he kind of thought, you know, had a very favorable impression of Django at that point.

So it's like, okay, if Guido's leading in that direction, it's worth taking a look at it.

So I did.

Uh then promptly had a position change, job change, same company position change, and completely left the Python world.

I had nothing more to do with Python from a job perspective for about 10 years.

Uh so I kept my eye on it.

You know, I always kept my fingers in the Python world uh as a hobbyist more than anything else.

Uh but over the next five years or so I saw where Django as a complete web framework really kind of gained the mind share.

But I never had a reason to work with it.

Uh then I actually did change jobs in 2014.

I had a company, another insurance company, hire me as a Python slash Django developer.

And while I acknowledged that I had no direct Django experience, uh apparently my Python knowledge was adequate for him to say, okay, you know Python, you can learn Django, and dropped me into the deep end of the pool.

So you were pretty early.

I guess it was in DC.

Was that you were based?

So it was maybe as local, but

That's the point.

It was I was living in Baltimore, working in Baltimore at the time, and you know, said to my boss, hey, there's this Python conference that happens to be local.

And he said, sure, no travel expenses, no hotel expenses.

And um, but it's funny that you mentioned um Guido, because I went to my first one 2019, 2019, um, after going to DjangoCon twice, and I was like, oh, it's gonna be like DjangoCon, but a little bit bigger, and it's you know, orders of magnitude bigger.

But at lunch the first day, I looked up from the buffet and it was Guido right across from me.

I was like, oh man, like huh.

I guess it sort of like made it real in a way.

Anyways, just to get my anecdote in there, but I just want to point out, yeah, it wasn't it wasn't like everyone was going to PyCon in 2020.

It's also interesting because when we interview people, there's quite a lot of people who when they move away from Python and Django professionally, their personal and community interest spikes almost as like an antidote to to their day job, and you know, eventually they they find their way back to uh the the fold professionally, but it can take a while.

Um, so that's that's not unusual.

I mean, I met some people that they may not even remember meeting me.

Um but the impression that they left on me, you know, the attitude towards people at that point, of course, again, you know, as you're saying, 400 people, it's a much more intimate setting.

Uh and I walked out of there, you know, knowing this was a group of people that I wanted to continue to associate with, which is something that I found lacking in a number of other professional conference environments.

I'll put it that way.

If I think about, you know, that's something sort of take for granted going to PyCon and DjangoCon, but most tech conferences are a monstrosity of sales, effectively.

Yeah.

You know, you go you go to Share, and uh are you either of you familiar with what Share is?

No, no, no.

Share is the international IBM uh users community, if you will.

Uh dates back to the late 60s, back when IBM operating systems were effectively open source, because you'd get, you'd buy your IBM mainframe, they'd send you the tapes with the source, and you had to actually build your operating system for your hardware configuration.

And so Share as a user community grew out of that as what sits in my mind as really the first open source community, even though it was not known by that name at the time.

And so Share was an opportunity for mainframers to get together and share patches and updates and things that they had done with the operating system to make it work better.

And so, but Share grew in the 70s to being, as you describe, these these ultimate huge uh commercial endeavors as much as anything else.

Yet they still at their core tried to be focused on the community, the fact that it's users helping users rather than, you know, under the sponsorship of IBM rather than being an IBM conference.

Um, and you know, they'd have U2 play shows, and it's it's just like that show Silicon Valley, where you'd have tech people on stage with musicians.

Rings very true.

But anyways, so Django cons, let's talk about those because

We get there.

I'm like, I've arrived, and you're like, hello, and I met you.

You're like the first face of Django Con that I saw.

So, how did you get involved?

And what's your story then?

I uh I know what I want, and I'm willing to do what I think's necessary to help achieve that.

I want good conferences, I want good PyCons, I want good Django cons because I get more out of a good conference than a poor conference.

I also know from having been on the other side of the desk in the working at and administering and running conferences, what a pile of headaches that is.

And I've done my fair share of work on that back end.

I know the headaches that come with it.

One of the most serious headaches is wrangling the cats, uh, volunteers, to actually show up on time when they say they're going to be somewhere to get things done.

So you're like the sergeant major.

You know, hey, you're here, welcome, we're glad you're here.

That's something I can do.

And I know by doing that, then the people in the back office who have more important things to worry about than greeting the people at the front can continue to take care of that.

And I can do that, quite frankly, it's really easy to do.

It's not that it requires a significant amount of effort, it requires zero prep time.

I just show up and I do my job.

Because like, let's be honest, people, you know, the first day they're there at like 7:30 a.m.

And by the last day of a multi-day conference, it's you know, more like 10 a.m.

when people roll in.

Yeah.

That first morning rush is always entertaining.

Uh, but I'm a naturally early riser anyway.

Uh I've worked, I've worked for many, many years like a six to two, six to three shift.

Uh, so it's not not unusual for me.

And then when you think about conferences being on the West Coast, that doesn't uh not help matters any because you know I'm waking up at 2 a.m.

in the morning, uh, first couple of days.

And again, you know, 3 a.m., 4 a.m.

in the morning, what else are you gonna do?

Well, you get up, you have breakfast, got nothing better to do, go downstairs, start pulling out tables, setting stuff up, and you're ready to go.

And, you know, so we got up and we we did bike rides every morning.

I think we were out the door by six, Carlton, right?

Yeah, it was good though.

Will we'll will obviously goes to the gym or something in his his normal life, whereas I'm a bit like, ooh, what's that?

I remember I remember those from childhood.

It's a bike, yes.

And and you're right, it is it's so overwhelming the first conference you go to because you don't know anyone, you don't know what's gonna happen, and then to to have a friendly face faces um sets the tone for the rest of the conference, for sure.

I mean, I was you know in that bucket, my first DjangoCon and first PyCon as well.

So it's a great way to meet people, as you said.

I mean, you know, if you go to conferences to meet people, instead of having to, you know, chit-chat at a table, if you work at the conference desk, you're just bound to meet.

Yeah, absolutely.

What's your sort of broad sense of all that?

make everybody feel welcome and accepted.

And hey, you are one of us.

It doesn't matter where you're from, it doesn't matter what you do in your job or not do, you know, student, hobbyist, whatever, you took the effort, made the initiative to come here.

You're one of us now, and we're gonna do everything we can to take care of you.

So that when the when the conference starts, there's always that kind of um half-hour presentation about you know what is a Django con and why is it so welcoming.

And you know, they have this idea about standing in the Pac-Man rule where you always leave a gap for someone to come and join.

And then, you know, this idea that how how many n is the number of Django cons you've been to.

Well, you know, M plus one, you've got to meet that many people each day.

So, you know, if it's your first one, you've only got to meet a couple of people.

But if you've been to 15, then well, you've got to get out there and you know, really get to know folks.

It's it's just little things like that.

You know, they're not little, they're massive, but they they really structure the day for me and they structure the conference and structure the mood.

It's not that it's not about Django, because it very definitely is about Django, but it's about the people working with Django.

And that's a mood that's that's I think can't be overstated because it's just so absolutely critical to the to the uh experience of the people attending.

They also they contribute to the Django Software Foundation every year, um, whatever proceeds they have from the conferences.

So um certainly for the US one, having having that organization, the people on it, Jeff Triplett, Craig Bruce, Adam Fast, there's some others.

Um, that's in a way thankless work, but hopefully people, you know, you go to the conferences and you meet them because they're the ones running around not at the conference desk, not speaking, but doing everything else to make it a great experience.

Yeah.

So this is um well, actually, before we get that, congratulations on winning this year's Malcolm Trudnik Award.

Um Thank you.

That's um no small thing, and that's an annual award for contributions to the larger Django community.

And I think in particular, a lot of the people who nominated you mentioned the Django Forum.

So this is something new, and you are, I think, far and away the biggest contributor.

So maybe you could let's talk about what the Django Forum is, and um, I'd be curious to hear about not just your involvement, but what you've learned engaging with so many people this past year or so on the forum.

Um anyway, um, but leaving that aside, trying to become serious here.

There's more advanced topics around where to put the logic, favorite third-party packages, but there's a lot of people new to the community who have questions on getting started and more fundamentals.

And in particular in that area, you've been very active.

So I'm curious what how those how have those interactions been?

Like what is that because sort of like being the registration desk in a way that people ask a question and you know they don't go to Stack Overflow, they go to the forum, which is um really has experts and you know, but so what what sort of patterns do you see, right?

Because a lot of times it's kind of the same question over and over that beginners have around getting started in Django.

I I know that I emphasize a lot the two, what I consider the two most frequently used or reference tutorials being the official Django tutorial and the Django Girls tutorial, which I think both are very excellent.

Uh they both cover a broad span of subjects from slightly different perspectives.

And I recommend both highly because they'll give you two different angles on something.

I know for myself, when I'm learning something new, I can't just look at it from one angle and expect to understand it.

I typically need to look at something from two, three, or even four different angles before I start to build a mental model that resonates.

And I still remember from seven years ago now what my sticking points were with Django and the difficulties that I had in learning it and moving from the other frameworks that I had worked with.

And I know I have detected that for the people coming in who are new to Django, you know, you can divide them into two very broad categories.

There are the people that are new to web frameworks in general, and they're just learning Python and they're just learning Django, and it's hey, I want to produce a web page.

And they have one mindset or one perspective that they're coming from.

On the other hand, you have people that may have experience in other web frameworks, whether it be Spring or.NET or one of the PHP frameworks, Drupal, WordPress, whatever, that are moving to Django, moving to Python, and they come at it from a very different perspective.

Because the first group is I don't know how to do X.

How can I get to point X?

And those are the ones that I try to steer to the tutorials initially because you know they they need that foundation something to build on.

You know, here build these basic building blocks.

Then if you still have problems, we at least have a terminology, a common terminology that we can work forward from.

But let's get some basics out of the way.

Let's make sure that we're using the same words for the same things.

Then on the other hand, you've got the people that are coming from a different framework.

So they already have some idea of I want to do X, and this is how I would do X in frameworking.

And the phrase that I use most often on that uh is don't fight the framework.

Don't try to make Django work like WordPress.

Don't try to make Django work like Spring.

You're going to create yourself headaches.

Don't change the framework, change your mindset.

I mean, quite often I do um client work and I'll go into a project where they, you know, they've got me in because they they they got a project that's struggling.

They've got to the point where they kind of can't progress further because of you know technical debt reasons essentially.

And more than nine times out of ten, the the issue is they're fighting the framework, they're trying to push it into the wrong way, and so you spend a lot of time moving things around so it starts to look like a Django app again, and then all of a sudden they can breathe, and it's like, ah, we can make movement now, and we can, and so it's not whether you're a beginner or not, go with the grain of what it's trying to do for you.

The documentation can only take you so far.

The document documentation can tell you how to do X, but most documentation for pretty much any framework I can think of does a pretty poor job of saying this is how you should think about X.

You know, this is how you need to approach the problem so that the solution you're trying to implement makes sense.

I think it's it's harder, especially for a f official docs, which are typically written by a a community, to maybe agree on that is one piece.

Um, but it's also the case that I've thought a lot about the fact that there's a difference between docs and tutorials.

And people confuse that and want both, and I understand that, but they're separate for a reason.

And a lot of the times when they're complaining about the docs, what they want is a tutorial that provides that that sort of top level um you know perspective as well as the details which the docs can provide.

Because the docs can't be a tutorial, it's already a massive well-documented thing to to be what it is.

Um but as you know, so the forum in particular, like some of the um questions I've engaged in are I think a little more in that top-down perspective where it around like like one of the ones um I think that a lot of people respond to was where to put the logic in Django.

Because as you progress in your Django journey, that's a very confusing thing.

And I think maybe especially if you're coming from another framework, because the reality is you can do it a bunch of different ways, and there are some best practices, but it sort of does depend on how not to fight it.

So I guess uh I mean I'll tee that up to both of you.

If someone says where to put the logic in Django, I I'll so my quick take is I would say if you can put it in the view, that's great.

Um, the model is probably better.

I would wouldn't dive into model managers unless you really have to, and I would keep it out of the templates.

That's my really quick take.

Um But there's a lot of ways to do it.

That's there's a lot of response.

We'll link in the show notes to the um there's a lot of responses in the community to this question because there isn't a simple answer.

Um, you know, there there are cases where model managers are the right answer.

There are cases where model managers aren't the right answer.

You know, for for any of those locations that you identified, there are specific situations where they are or are not the right answer.

And so I don't think you can make a blanket statement that your logic always needs to go here.

I mean, that's the thing, is like that is the correct response, but they still say, okay, but but how?

And part of it I've seen too is sometimes people uh dep depending on where the what their background is, not understanding what Django can do and what Django can't do.

So a lot of times they want to like pull in data from somewhere else, an API or a database, and they don't really know where to do the logic on that.

So a lot of times it's well, Django's not gonna clean your data for you.

Or I even had a long back and forth with someone who was like, What does Django even do for me?

I was like, it does the web part for you, but you know, because he this person wanted, you know, I I love the projects that beginners have because they're just there's they're so you know, for those of us with experience, it's just like that sounds awful and like that's gonna be impossible.

But they're like, Well, I want to pull in this and this and this and make it real time, and you know, um they're sort of unencumbered by by reality, which is good because it makes makes us think about you know what could happen, but so much of it is outside of Django's scope, wanting to apply logic to things, which is like, yeah, write a Python script.

You know, Django's not gonna Django can't help you with that.

Anyway, some of the some of the emails I get with Carlton, what's your response?

You've been quiet.

So um, you know, Ken's right, it depends.

But one one analogy I always go back to is the let this idea of application layers, right?

Where you've got say the um the model layer in the middle, and then you know, a validation layer around that, and then you've got a view layer perhaps, and then some some UI bits around that, perhaps.

You know, this this is an old software architecture um way of thinking about it.

And I think that works quite well with Django, in that you've got the model layer for you know, business logic.

And so one thing I do use managers for is to create a custom, say, create method where I need to pass in a couple of parameters and there's a bit of special hunky-dory logic there.

I want that inside a manager, not or inside something.

I want it encapsulated so that the rest of my code doesn't have to see that nasty.

And so I quite often use um managers or custom query set methods for that kind of logic because I the view then can pass into the model manager just what it needs, and then the model manager does that that business logic.

And then what does the view is left with?

Well, the view's job is to take an HTTP request and turn it into an HTTP response.

So is this logic related to view handling HTTP?

If it is, it belongs in the view.

Sometimes you you get some data from the view and you want to pass it to the model layer, but that's you you can't just pass it straight in.

You want you don't want the model layer throwing out d DB errors because you passed it bad data.

So that's where we'll have a form.

And sometimes form logic can be quite complicated.

And particularly a model form, when you hit save, it gives you back an instance.

So any kind of logic about validating the data and getting it ready to pass to the model layer, that lives in the form.

And then I don't know, you might have an HTML button that you it it has different um values depending on I don't know what's going on on your site.

And so you might create a template tag for you know, site app button, and then you might pass it a parameter and it it does all the fancy logic to generate the HTML that you don't really want to put in get context data.

I mean you could call it from get context data, but you know, then you'd need a little helper function to keep it tidy.

Well, it could just live in a custom template tag, which are really easy to write, folks.

You know, you know, the DTL is actually super powerful.

Um so again, it depends.

But I that's how I kind of think about it.

I try and think of what layer does this, and and what I don't want is the model layer having to reach out and do something for the view layer.

I don't mind the view layer reaching down to the model layer and saying, hey, please can you provide this service for me?

But what I don't want is it the other way around and try and keep some sort of cleanliness like that.

And but beyond that, it's impossible to say without a concrete example.

Um, we'll put in the notes.

Tom Christie has a post from 2014 sort of to your point on Jenko models, encapsulation and data integrity.

That is such a great post.

It is it's just amazing, and more or less that.

I don't quite agree with him about model forms at the very end, but the rest of it is dead right.

And there was a debate recently, um, somebody wrote a book um uh uh about I can't remember the exact title, but it was about um creating a service layer, and they were very anti-um Django and the ORM in it.

And there was a couple of posts, one by James Bennett and another one by um Luke, whose surname escapes me momentarily.

Played something like that.

Yeah, replying, yeah, replying about you know how you create a service layer in Django or how you avoid creating a service layer using the ORM the way it wants to be used.

Like and again, this goes back to cutting with the grain of the framework.

But I th I think part of the thing is, you know, we like if I was gonna teach someone this, you almost want to show them, well, here's the five ways you could do that same, you know, save method so that they have the context to understand why one is better than the other.

Because a lot of times they don't know how to do any of the five.

Um so to talk about, well, this goes here, that goes there, they sort of need the reps to understand how the pieces fit together, I think, right?

Like I've thought about like how many different ways can I do a to-do app or uh even Hello World.

Actually, I have a post on Hello World done five different ways, which I think is quite clever, but I think I haven't explained it well enough to get it kind of get at this, you know, multiple takes on the same issue to show how the pieces fit together.

Um, because it does take quite a while to understand how the pieces fit together in Django.

I made a I made a whole GitHub um repo for that and there's been discussions.

I don't know if I do.

Um uh I'll I'll put the links in.

I ca yeah, because I think it's the thing is is that by the time you get to showing how to do one thing five different ways, you you've lost most people.

So, you know, like this Hello World one, I think it I almost don't I don't mention it to beginners because I know it's just gonna confuse them when I'm like you don't actually need to have a views.py file.

Like you can stick the view in there and you know, and then Carlton's thing is just you know, that's mad scientist realm.

Um but I'll put the link in there.

I should link to it.

I would I have created and do create single folder Django apps, right?

But I a single file Django app.

Nah.

So I see I'll add it actually after this.

So I have it, it's Jen Jalink Django Hello World Five Different Ways, and I'll put a link to Carlton's talk.

Yeah, because I have a whole repo with the code because Carlton put the code up on his slides, but um yeah.

How quickly can you lose can you lose uh you know someone asking a question about Django?

Like, and that's that's why I like books, like you know, guides around.

I think we can't have it all in the Django docs, as you said, but like books like yours where you can go pick it up and you can go through it, and there's several different projects and there's different things and they teach you the different aspects.

I think that's an essential resource on the side.

You can't just have it all in the the Django docs because they've become unmanageable, they're already, you know, massive.

I don't overwhelm them.

But maybe for a next book, it'd be like, well, here's our here, you know, here are all these different ways you could do it.

Um that might actually be an interesting thing.

Though I I feel like it, uh yeah, it's hard, hard to know what people will want, but they should they should go through something like that if someone felt inclined to make it.

But speaking of Django, um, we're coming up on time, Ken, but uh one of the questions we wanted to ask you was ways to improve Django in the broadest sense.

You know, if you had a magic wand, what are things, you know, technical, community, otherwise, what do you think are some ways that Django can improve itself uh going forward so it stays relevant?

I I've known from talking to many people, how I use Django is really different from most people that I talk to.

I'm not sure that I actually have a good opinion on that question because for what I do with Django professionally and hobbyist, out of the mainstream, in terms of, you know, you think about Django, it builds websites.

And so what is a website?

A website is designed to present information to people.

Okay, I do that, but the appearance of the website, how it looks, how a person interacts with that is much less important in my job than the actual data that I am retrieving and displaying to the user.

Uh I my websites will never receive any awards other than possibly a Razzie for uh their appearance, for their look and feel.

Because I'm writing websites for internal company employees in very small numbers.

Uh you know, my average my average website has two users.

That's correct.

And look and feel just really isn't an issue there.

I just need Django to be able to go out and collect data from different sources and present that in some way that an engineer can look at.

For example, uh my current project that I'm working on, I'm decoding TCP dump PCAT files.

And I am decoding them and presenting packet level uh displays so that it's in a sense it's Wireshark through a browser.

Yeah, I was just

It's Wireshark in the browser, but you got there first.

It's not presenting the full frames, it's highlighting specific data fields and organizing that so that an engineer looking at the network traffic sees at a glance what it is that they're interested in saying.

And that that's very frequent.

And you know, these kind of internal data analysis type presentation, I I think that's a lot.

Uh you know, obviously the agencies, the you know, you go to the conferences, it's like, oh, we work on this big site, and that's user-facing, but I think a lot of people are using Django in this way.

Um, you know, part of it is I've gotten so used to Django as it is, I've become very comfortable with what I'm doing, with how I'm doing things.

I think the biggest improvements that I've seen over the past couple of years has actually been in the tooling around Django itself.

You know, had you asked me this question three, four years ago, it was like, find me something that lets me get rid of Eclipse, please.

Uh and with Visual Studio Code now, Eclipses ancient history.

Um, you know, so it's it's all the tooling that is, you know, maybe I'm just becoming more aware of it, but things like Black or Pep 8, um you know, other other facilities of of tools around Django itself that is making it a more complete environment that I'm seeing the things now that I was used to working in a Java Spring en

vironment or.NET.

You know, I'm I'm seeing this type of first class support around Django.

So it's it's not that I have any recommendations for Django itself.

It's that I'm giving huge kudos to the people who are working around the fringes, you know, who are doing things that are adding on these external features though that make working with Django that much easier and that more seamless in terms of keeping things moving forward.

And so if to follow up, then what would what would you say say the last 12 months is your favorite package that you found that fits in that club?

Yeah, yeah, yeah.

Come on.

So I think that's why it's the top of my one.

Okay.

You know, I started out using it as an uh Eclipse replacement, you know, basic editing and putting projects together.

But as I continue to work with it and learn how it works and understand how to do things with it, uh the different configuration files, like custom launch.json files and and using the debugger with it, I've just more integrated, I've gotten more in-depth, more comfortable with it more as a tool than just an editor.

And so that's been that's been my biggest improvement in my workflow over the last year.

Okay, super.

Yeah.

I know, Carlton, you BB Edit, right?

You have one that you get to occasionally, but

I have it open all the time because um as great as VS Code is and its multi-file search is very fast.

When you're trying to pick through, say, say I'm trying to um pick through a um a trace in Django and I'm trying to have all the source files open and all the rest.

BB Edits multi-file search is just phenomenal, and you can you can have the different searches open in different results windows, and you know, VS Code doesn't like you doing that because it's got to fire up a JavaScript, it's basically got to fire up a new instance of Chrome for every window you open.

Like that's fine, but you can only open so many, whereas BB edits a native Mac app, and it's it's for that kind of um forensic research through a big code base, it's indispensable for me.

I mean sometimes I just want a different editor.

I want something my Atom config is very, very, very basic.

And it's sort of like in a way my BB edit, because my VS Code is all customized, and sometimes I just don't want to deal with any of that.

I just want something simple.

Uh nano on occasion.

You know, if I just need to hop onto a server and make a quick patch or something.

Yeah, you've got to be comfortable with lots of tooling.

Can I just ask?

Uh, but I do a lot of my development in WSL.

And that is absolutely required for the stuff that I do.

Um, so yeah, it's it's Windows, WSL 1.

Uh, I do run uh VirtualBox for some local virtual machines, and then my server room, all of my servers are various shades of Linux.

Okay, cool.

I need a server room.

That sounds like a nice thing to have.

What what would you say are good first steps for someone who's using Django but wants to get more involved?

I think it I find the forum to be more personable, more personal, more personable than the mailing list.

Uh Django Users is a fine mailing list, I still read it, but I was never really active on it because it just for whatever reason that interface feels impersonal to me.

And it's like, please join the join the forum, browse some messages, and if you've got something to say to chip in, answer a question.

People don't bite.

You know, it's I I I remember my first couple of answers, there was a lot of trepidation.

It's like, well, if I answer this, who's gonna jump on me and say, you're wrong, you're wrong.

Um I've been corrected enough times, but you know, that's all part of the learning process.

Right.

Um, you know, and for that I am grateful.

Because I would say beyond not looking very nice, the my biggest issue with Google groups is it's very hard to surface past conversations.

So there's 10, 20, 30 takes on the same thing, and the forum is nice to have it in one more of one place.

Um, and it's easier to read through.

And you know, I think so similar to Stack Overflow, it's there's sort of one place for certain questions around a different topic.

So I think that's helpful.

So what about offline?

I mean, obviously attend a Django Con and sounds like you know, put your hand up to volunteer.

That's yeah, that's true.

Um unfortunately that that kind of faded away uh for a couple different reasons, uh lack of a place to meet being a big one.

Um but you know it it's it doesn't take much to actually try to form a local group.

If if you can't find something local, it doesn't hurt to say uh put out some uh flyers metaphorically, you know, go online, meet up, what's it, meetup.com, that you can you can create local meetups, uh, or even uh show and tell in the forums, probably a place that you could say, hey, I'm looking to meet people in area XYZ.

Uh and try to find a local community, and if there's not one close by, even see if there's one that you can get started.

Uh but I certainly there's a lot to be said for meeting in person.

You just need a handful of people.

And often it's a Python thing because Django is a obviously a subset, so you know it's fine if it's a Python meetup.

Um I I in Boston where I am, there's you know a lot of developers, so there's Python and Django, but usually the Python one you can start talking about Django there too.

So, anyways, I think we're we're at it at about an hour.

Um thank you so much for taking the time to join us.

Yes, super.

Um, congratulations again on the Malcolm Award.

Thank you very much.

This has been a pleasure.

Will, Carlton, it's always a joy to be able to talk with either one of you.

Um, looking forward to the day when we can all meet in person again.

Touch 2022 now.

Well, hopefully, fingers crossed.

Um so um thank you, Ken.

Um, for everyone listening.

You can find us at Chat Django on Twitter and DjangoChat.com for this and future episodes.

We'll see you all next time.

Bye bye.