Transcript: Star Wars and Django

A week Fortnitey?

I don't know how often we do it.

A podcast on the Django web framework.

Um Carlton Gibson joined us every by Will Vincent.

Hello, Will.

Hi, Carlton.

Hello, Will.

So thanks, thanks for coming on.

This is really exciting to have you on.

Yeah, thank you.

Like hang on.

Industrial Light and Magic, you do really cool films.

So how on earth is Django involved in that?

Could you how how'd you get into programming?

What's your backstory?

How you know and how does Django play a role in what you do?

You want to go first?

Uh so I actually graduated in computer engineering.

I started working in the hardware industry, and then I've changed industries a couple of times and end up in Visual Effects uh almost by accident.

And then uh it's been like seven years now since I've been to Visual Effects, and uh, you know, a lot of people don't know anything about Visual Effects, like I didn't, but we actually have this massive infrastructure uh to render frames, right?

We have like petabytes of storage, thousands of CPUs in a farm to do batch processing, we have a bunch of services, we have many data centers, and they are all there to produce these great pictures that we see in the screen, and that we don't even know what they are, how they are made.

Like because they're you know that's a lot of a lot of compute.

No, we mostly have our own data centers, uh, and we have our own connections between the different data centers.

So we have data centers in Sydney, San Francisco, Vancouver, Singapore, London, basically everywhere we have an office.

Uh we've also been using the cloud a little bit recently, uh, but cloud ends up being very expensive for us.

Like our workstation has like you know 200 gigs of RAM and 64 cores to be able to open those heavy scenes and those uh you know do some rendering.

So you can imagine how the cloud you know can be very expensive when you're paying for those sort of machines and very high-end GPUs too.

Uh yeah, I basically come from you know more recently more DevOps, backend uh systems engineering, and uh I actually don't have a lot of the knowledge in the proper, you know, visual effects, and you know, I've been in the industry for a while.

I help people with workflows and whatnot.

But uh I think yeah, James has been much closer uh to the product than I have.

So maybe that's a good segue for you, I spad.

Yeah, sure.

Um and I started at ILM right out of the school, um working as what we call a technical assistant, uh, which is a way of saying I worked from midnight to 10 a.m.

watching these renders on these massive machines that Andre was talking about.

Um I then you know followed the support path role, uh helping artists troubleshoot issues uh with their scenes, um, until eventually I moved into the production tools team, um, where we develop tools for interacting with uh uh data such as like what shots need to be done, what tasks need to be done, um, generating media, those sorts of things.

Because I know Andre, you gave a fantastic PyCon talk in the show notes on sort of the pipeline.

And you know, James, I can see Fluent Python on your bookshelf behind you, so I know we're gonna talk about Python, but what is what does that curriculum look like?

Because I have no idea what it what what that would uh entail.

Uh yeah, so um it was a mix between art and programming.

Um so we learned, you know, how to use Visual Effects software, uh, create images and render them.

Um naturally I kind of gravitated more towards the technical concepts, which is how I ended up in the uh position I'm in now.

Um we did things such as uh learning to write shaders, um, which are programs that determine how light interacts with surfaces, um as well as just you know uh compositing, putting images together, all kinds of things.

Because I know, Andre, just from your talk, you mentioned that a lot of the engines themselves are written in C, but the glue that puts them together is typically in Python.

Is that correct, James?

Uh we did we did do a little bit of C in that program, if I remember correctly.

Um, but we never got into like ringing full-fledged renderers.

Um it's more of like a computer science thing.

Uh you can think of it as like the program was learning to use the end result of those tools, if that makes sense.

And all those renders and C, uh, you know, simulations and whatever needs to be super fast rendered in C offers a Python API.

So basically every tool that we use, uh, we use you you have like a Python binding, a Python API that you can import into your environment and you can interact with the scene in real time via Python.

Uh let's say you know you are making a I don't know, a space battle and you have a spaceship, then through Python you can you know create 10 spaceships instead uh using an API and rotate them and change uh you know their texture or what have you, uh via Python APIs, uh very similar to how you do import requests or what have you, but you actually import the DCC we call DCC digital content creator uh APIs.

Yeah.

Um so is that so what is I so I well I have to jump in.

My I told my wife I was interviewing you all, and she's a huge Mandalorian fan, and she was like, what about that huge screen they use to film it?

Right, the the volume, I think, just to like skip ahead, which I believe uses Unreal Engine, which is like a video game for the background, and then would that still use Python to move things around?

Because I've seen videos where they can, you know, right there change things.

Uh but uh yes, definitely.

It's not as far as I'm aware, we haven't been using Unreal as much.

We have our own render engine that we uh wrote in-house uh for reasons, and uh yeah, I don't think I'm the most qualified person to talk about that, but for sure there is Python there.

Uh we run our own uh uh software that we wrote in-house, and there is Python bindings for all the different things.

I do think a lot of the really heavy lifting is done in C though.

We have some genius engineers working on that side of things.

I don't know if you have anything to add, Spad.

Um we we have a lot of engineers writing some great tools uh for interacting with the screens.

Um we also have uh it we've created interfaces like on I don't know how much in detail can go, but

I I meant like legally.

Well that too.

So but um we we've developed like interfaces on the um the iPad uh that let's do it.

I saw that on the the volume.

Oh is it?

It's from 2020.

It was showing someone with the iPad and saying they were you know moving it around and showing the screen moving, so that's out there.

Yeah, all right.

Well that's good.

Um yeah, so typically we'll have someone on set with the iPad, and what they'll do is they'll manipulate the the light in the scene.

So in typical film production, if you want to change the lighting, you would need to like move your lights around.

But with the volume, what we're able to do is with the iPad create these squares of light up on the walls uh to illuminate the scene.

And that allows the director to get much faster feedback.

Um and all the tooling around that, I think is I believe is written in Python to kind of stream that information over to our proprietary software.

It's the 21-foot screen and then also the ceiling, right?

So there's no actual lights, right?

It's just LEDs everywhere, pretty much.

But I know that we do use the LED wall a lot to manipulate the light in real time.

Right.

As we're working.

Sorry, Carlton.

Right?

Isn't that also la last point, isn't that also true that like, you know, lighting is super hard, but then you have a reflective surface, like that really magnifies more than skin, right?

The issues?

I mean, uh the I I don't think we could get as good looking results without the volume, uh, because the reflections in real time on the Mandalorian suit of armor, like that that's all from the wall.

Um, other in the old days we probably would have used a green screen and it would have been kind of tough to do that.

It's like reinventing filmmaking to some degree.

Absolutely.

James and Andre are in Vancouver and Will's in Boston, I'm in Spain, so like they've got a nice little chat, and I keep trying to butt in, but there's nice little pictures of C, so I can't ever get it.

It's fine, you know.

Um what I wanted to ask about was the um the the change over the last say decade um or you know or longer in terms of because you you've used lots of phrases like real time, and you're talking about having an iPad in hand and being able to drag components around, and that's and that's just raw processing power, right?

That's that's that's stuff that wouldn't have been possible, you know, five, ten years ago, or or even you know, can you talk about the change in the the technology?

And um let me give you what one example was that I I saw a line from the Pixar people about rendering um Toy Story 4, and they were able to render it basically in uh in real time as they were as they were producing it versus when they did Toy Story originally 20 years previously, you know, it would take several hours to render a single frame.

Uh, but I do think movies keep getting more complex too, and we keep having higher resolutions.

So it's almost like doesn't matter how much it evolves, artists on computer graphics are always using everything we've got.

So uh we definitely do a lot more.

No matter what decade you're in.

Basically every single show you watch on Netflix or Amazon Prime or what have you has an immense amount of VFX shots, probably more than movies than had like five or ten years ago, even though you know they don't even notice it.

Uh it's out there making for a very realistic experience.

Like what let's start let's start with that.

So right, so you have this whole C things glued together with Python, you've got massive rendering and databases.

Where is the where is the the Django small bit in all that?

Uh I think, you know, uh I'll give a little bit of a historic perspective, plus uh, you know, and and spad can get into the details that works for you, spad.

Uh co.

But I think uh yeah, historically, you know, VisualFX was just a bunch of Python scripts on a big shared folder, and then you add that folder to your Python path, uh, and you version those Python scripts.

I think that defines uh you know VisualFX pipeline to some degree.

And I'm talking about you know millions of lines of code.

So it's not like some Python script, it's actually like terabytes of Python scripts.

Uh but uh I would say that with things getting more complex, we have a multiple data center, doing more shots, we needed to scale that to some degree.

And I think a good way of scaling it is you know decoupling a little bit of the client side dependencies from the business logic behind the service, and that's where service starts making an appearance uh in Visual Effects, I believe.

And also, you know, some people want some fancy Web UIs done on React instead of like QT or you know some more desktop-based apps, which also a server helps with.

So I think that transition has been happening in the Visual Effects industry a little bit slowly, toward services.

Uh, and I think you know, historically at ILM, we are using each group has a lot of uh independency to independent, they are independent to choose their own tools and frameworks, and we end up with a lot of different teams speaking different tools.

For example, a team would use Tornado, a team would use Flask, and it made it super hard to be cohesive, I feel, uh, how we deal with authentication, how we do with databases.

So we sort of standardize on using Django uh to building some of those services that abstract the business logics away.

Uh we set up common some common libraries that we use, like uh Django REST, for example, and other things, uh, like how we connect with LDAP and uh et cetera.

We just made the process of developing a service more streamlined uh that allowed us to have Ansible plays or Docker files that are standard across the teams and uh et cetera.

Uh to some specific examples on how Django is used, maybe Spad, you can go ahead.

Um actually, if you don't mind, I I just want to expand a little bit on what you were saying about the the scripts in the pipeline uh and whatnot.

So um, you know, before I was on this team, um I was on another team that uh worked as kind of the the go-between between the projects we were working on and the engineering teams.

And we have some of the most the smartest artists in the world working at ILM.

Um and as a result, they like to you know write Python code.

Uh so managing all the scripts written by all these different people across all these different teams has always been quite a challenge for us.

Um, you know, and also that that move from QT because all of our third-party software, Maya, Nuke, was all written in QT.

Um, so that's what we were using for a long time before we made the shift to um using uh web UIs and whatnot.

Um to get back to the specifics of the Django stuff, um what one area we're using Django is to deal with uh subscription management.

So for an artist, uh the typical workflow is they'll do some piece of work and write out some media, and then they will submit that media for review for either the director or their supervisors.

And we have a lot of artists submitting a lot of media, and trying to route that media to the right people is a bit of a challenge because you have we have like five different sites all working on different projects with different people.

Um, so we developed a service that lets users uh subscribe to different tasks based on you know what what the artist is doing.

So, for example, if I'm a director, I could say I only want to see lighting media from San Francisco.

Um so they can go into this web UI and edit these filters, and every time the artist submits media, it goes to the correct people based on the filters that they've created.

Even there's this site DjangoPackages.org that Jeff Triplett has taken over that um I was we're just going through grids and opting into things, and I can't even imagine how complex it is to actually do that at the scale you're you're talking about.

I mean, can you you know, because with code you can use version control and git.

Like how do you track changes on an image or audio file?

Is there a way or what what's the process for that?

Um what we do is we track submissions.

Um so if the artist uh they'll submit something and they'll get some notes that are attached to that version, the artist will then act on those notes and submit a new version.

And um we keep track of all those versions associated with like a task that needs to be done.

And basically, whenever someone publishes a new version of a model, a simulation, a rigging, that's a new asset.

And then uh you basically track some metadata with the asset, a bit like S3, uh, and you have like versions uh for the assets, you have dependencies between assets.

So let's say I'm compositing some scene and the model changes or whatever, then I get a notification like, hey, there's a more up-to-date version of the Iron Man model.

Uh, you know, do you want to update it or what have you?

And uh yeah, there's a bunch of things like that that we have to tracking data across the pipeline is super important as you know, as I've mentioned, we have a lot of storage, and those assets are massive.

Like a texture can have like terabytes, uh, you know, and it's it can be very clumbersome to keep the disk space uh tidy as we have many shows and artists and assets being produced.

But then when you get into doing you know actual visual effects, well, yeah, that's where these sort of superpowered computer systems really do.

Yeah, several questions.

It's such a good introductory talk.

Um, thank you.

We certainly have lived through that switch in the Django world.

Is that is that switch complete or like what version of Python are you are you using, or is it all over the place?

Because it's it's kind of all over the place in the Django world, but it's pretty much all Python 3 or

Uh I think you know, the Dccs like Maya, Nuke, uh, and other software the Visual X artists use, they ship with a Python interpreter, and that Python interpreter has still been the standard Ping 2.7.

There are some of them that are in Python 3 uh nowadays, or you know, I feel the industry is slowly moving towards Python 3.

We've certainly spent huge effort on migrating uh to Python 3 recently, a lot of those scripts.

And uh as I've mentioned, we're talking about millions and millions of lines of code uh from Python to migrate, so it's very hard to justify the business need for it, I feel, because you know, ILM has been around for 40 years, uh, and we have a lot of old code uh lying around, and you know, but they are working in the business function.

You know, it's still as Carlton and I joke, every code is like just good enough to not break.

All of our service side code or most of it is written in Python 3, I would say.

When you don't have a dependency in the runtime of the artist software, which is Python 2, we can do Python 3.

So really we're trying to make all of our code compatible with 2 and 3.

All new services start on 3.

Uh but yeah, I I think we are winning that battle.

It's lowly spad.

I don't know if there's anything you want to add.

Um, we just had a big push across our teams to convert all that artist code over from uh Python 2 to Python 3 compatible.

And it's it's given us an opportunity to do a lot of house cleaning, which has been great, like archiving stuff that isn't used anymore.

And it's been an interesting exercise to figure out what's used and what's not.

Um I think in hindsight it would be great to have more analytics on a lot of stuff.

Um so I think I think that's a great thing to build in if you have a lot of software to maintain.

Because smaller scale, but still pretty massive amount of work.

Lost it forever.

And you were just supporting 2.7, you know, and then 3.2, 3.3, 3.

you know, 4 as it as it started coming out, and you were running the test suite against each of them.

And it was a real, you know, at the end, it was it got to be a real pain.

It was like, oh, we are we really still supporting 2.7 here.

And then I remember when it was like, no, actually, it's send of life now, we're starting to drop it, and it was like, ah, what a weight of it.

And they they got it where you had you had this nice world where you could write library code, which was both 2.7 Python 2 compatible and Python 3 compatible, and it sort of went on, it was like, yeah, this is doable, this is no problem.

But oh, when you could delete all those objects, you know, support from objects, and when I can't remember the things, and to get rid of six, this you know, you you weren't able to call the string functions, you had to use the the the six compatibility shim, and it was like ah, and when all of that dropped away, it was just like, oh, like a breath of fresh air, it really was.

Um, but you still get you know, you you break something which is python 2 compatible and you still get issue reports opened as like oh you've dropped Python 2, and so well Python 2's been end of life for a couple of years, so I don't feel too bad about dropping it, but clearly there's still lots of people using it, right?

There's still it's still it's still really out there.

Like 3.5, 3 like because I know you have to.

Yeah, we'd yeah.

We're not talking terabytes of code.

Um I mean, so okay, here's a good question.

Tests, right?

Because so I'm I'm a digital artist and and I write up a little Python script to manipulate my my 3D scene I've got environment in front of me.

It works, and it you know, I I can do exactly what I want and I've bashed it together, but I haven't written any tests for that ever.

Like no is that yeah,

Yeah, so what what we found with um a lot of the artist scripts is you kind of have to have a understanding of the software to test it.

Um so this was a good exercise for our team um because a lot of them hadn't touched artist tools, so they got to learn a little bit in that regard.

Um ideally, I mean all of our software that we write on our team has tests um for the most part.

And um that that's super important to us and something we want to continue to doing, continue doing going forward because it just makes things so much more maintainable and upgradable.

Um yeah, for artists' scripts, um, it's a little hard to enforce because we have a bit of a wild west um of scripts built into our pipeline where anyone can commit anything and use it.

Um I don't know if you want to expand on that, Andre.

We have a uh software management system that we wrote in-house, a little bit like you know, Peep and VirtualWave, but it's our own implementation, and that basically tracks uh RT software so that you can version up, version down, you can easily roll back.

Like rolling back software for us is like a one-second operation.

You basically change a sim link to point to the previous version.

So at the end of the day, it we do release you know hundreds of times a day uh those scripts and software.

So we release software quite often and we make it easy to roll back.

And for the RT software in particular, the Python 3 migration, we in our software management system, we added a check that it basically tries to compile the software to Python 3.

Uh and if it fails to compile, that means you know you cannot release it anymore because it's not Python 3 compatible.

So we enforced the dash level.

We didn't did the you know the unit test or whatever, uh, because it's just not doable, I think, uh, for our problem right now or problem space.

But we did enforce that it at least compiles with both Python 3 and 2 so that uh you can make sure that it is compatible, and if not, you have to do a dash-force, or some people still do it, but you know, at least we track everything.

We have like a web UI and the stuff.

I mean, I've often asked you for advice because there's at one extreme is test-driven development, do the test first, 100% test coverage, and then there's also you know, happy path programming, test it, and then when something breaks, write another test.

That's more the iterative approach, I think, Carlton, that you've advised to me at least as well on this.

Like, you know, to test even in the the quite, let's say, um mundane realm of web development, let's call it, where you're testing a web UI, that's hard to test.

It really is.

You spend a lot of time writing, you know, UI tests and they're really flaky and they fall apart.

I just can't imagine there are tests.

It's even possible.

Yeah.

Software.

I hope they care about software developers, but not about software.

Uh you know, at the end of the day, our business is to ship uh pretty pictures for the image for the movies, is not to ship software too, right?

So I think uh that there is a trade-off there.

And uh yeah, usually we just need to know how to manage it.

You know, if it's some very critical service like the asset system, you better expect it has a great test coverage because you can bring down the whole studio globally if you you know release a bug and you know Marvel is not gonna change the release date of a movie because we can't render it or whatever.

So uh you know, some very core pieces of the software I think do have the love and care they deserve.

But this more scripted side of things, which is a lot of the software we have to maintain.

Uh yeah, it doesn't need or follow the same uh scrutiny, maybe that's the word.

Like it like this is a this is a a script I'm using to manipulate a 3D scene that I've got in front of me in a in a GUI program.

I don't need it to be you know unit tested in the same way.

It's it's help it's it's a tool to help me what with what I'm doing, not you know, core bit of my business logic.

Whereas compared the Django app you were describing where you're doing the subscription tracking to asset changes, that sounds sounds like the sort of thing that would be susceptible to you know much more request testing.

They lost it, except some art like producer was on maternity leave and had a copy on her computer.

Um I'm just curious for you as professionals, what what does that story say to you?

Because I hopefully that's still not possible.

I mean, I guess you couldn't store a movie on a computer, but like how do you how do you test or not cover someone like you know, nuking everything, right?

Because that's a pretty crazy story.

I think they actually did thought they didn't have it for a number of days.

And there's

But we could catch up, we caught up it on time.

That must have been like five years ago.

I think it was a bug in Docker itself.

Uh but uh yeah, we we do have you know a big, big NFS storage, and we have policies for backups.

So I do think we are covered there.

Uh, but you know, some of our data centers use tapes for backups, it is a lot of storage.

Um but yeah, uh I don't know.

We have software to do the operations.

I can artists wouldn't, you know, as artists don't have root and they won't be able to RMRF uh a show partition, for example.

They have to use some tools to do the this cleanup and et cetera, that check their permissions and uh whatnot.

Everything is tracked, or almost everything is tracked.

Spad, I don't know if you wanna add to it.

I mean, we um the tape backups are definitely an interesting area.

Um fun fact about the tape machine that's actually the inspiration from uh I don't know if you guys ever seen Rogue One, the uh the movie.

Do you remember the giant machine that took the tape out?

And she looks at it in the movie?

Do you know what I'm talking about?

Fantastic basement of uh

Or I guess maybe that's not Star Wars.

Rise of Skywalker.

That's my first credit on a Star Wars movie.

Uh I think James, you signed here somewhere.

Yeah, yeah.

Uh so that was my first Star Wars at ILM, and uh yeah, we did some pretty amazing work there on the Visual Effect side.

It must be quite awesome to be credited on a Star Wars film.

They're for eternity.

Yeah, definitely.

I mean, Andre, you said you found your way in.

I mean, so let's say someone knows Python.

What like what advice would you give them or what you know how do you go the technical route into apply?

Yeah.

How do you screen?

Like what what's what kind of

Uh for example, Spad mentioned he started as a technical assistant, which is a TA.

You don't really need a lot of advanced Python or Visual Facts to get there.

You mostly need to script stuff.

That's usually the entry level of the industry, where you you know you're gonna be tasked with ingesting some meta uh some tapes of some data from the client into our pipeline, watching some render jobs, seeing if they are having issues and bugs taking too long, and then you start scripting some stuff to make your job easier, and eventually you make your way through the pipeline as a pipeline TD, uh, which is a pipeline technical director, or in core pipeline, our group, or in RD

There's usually a little bit of mentorship there, and depends where you want to go.

Some technical assistance assistants end up being uh going to editorial or being an artist, but I think that's the entry level.

However, if you do have some experience with software, Visual FX is always hiring uh people, and if you don't have Visual FX experience, that's totally fine.

Uh I'll say just go to like ILM VFX Careers.

You can just put on Google.

We are hiring right now across all levels uh to join our team.

Uh if you know if you have the traditional back-end full stack experience, I'm sure gonna be a huge asset to our team.

And we can teach you the specifics of Visual FX.

We don't expect you to know that.

Um yeah, hopefully that answers the question.

Spad, do you want to add something?

Um ILM has a wonderful culture of fostering talent and empowering people.

Um, you know, as as Andre mentioned, you know, I I started out working midnight to 10, and I the most Python experience I had was writing scripts, you know, uh that monitored a farm and fast forward seven years and you know, writing Django services, deploying with Ansible and Docker.

All this was learned um through ILM.

So we we are always looking for people at all levels, um, and we love gl growing with from within.

So apply.

Yeah.

I mean, even at Megacorps for traditional software, it's pretty rare to actually have it from what I've heard.

But sorry, Carlton, go ahead.

There's nothing, you know FX-y about that.

So you don't know that you don't have to be an FX artist to do that stuff.

I do think it helps.

Like if you have, you know, you know how a Visual FX pipeline actually operates, or you can talk with artists and understand their pain points.

Like it is helpful, right?

But it's something you can learn uh in the job.

And uh, you know, we have product owners for some of our products, internal products, that will be that interface with artists and technology.

Um, yeah, you got to talk with a lot of people.

We're very collaborative.

So yeah, if you are interested in this domain, I can say it's pretty fun.

Uh, you know, I wasn't even aware it existed, and I absolutely yeah, had a blast working on this domain or have it's not your boring crowd app that a lot of devs complain about.

After a couple of years, it's kind of like the same thing.

Well, but but so on that on the career thing, so um, because James, so you've been at ILM your whole career, but Andre, you've you started off in hardware, you've been at a couple other visual effects places.

I guess I'm just curious what so in traditional, you know, in web software, people kind of bounce around a lot.

Um it sounds like maybe at ILM it it's not so much the case, but you, Andre, because you came in a different route, you've made that transition.

So I guess I'm curious what what causes someone to move around, right?

Is it new challenges?

Is it new learning environments, or what's I mean, I sh I assume salary as well?

Like what what's give us a sense of that world and the career tracks if you're not from the

inside ILM?

So you've like how did you first get into VFX and then you've you have been at like when you gave your talk, you were at a different effects house?

I was there for I think a year and a half at the time.

Um yeah, I don't know.

I think I was just looking for a job.

I was working on a startup at the time in London called OpenDask, and we were having some troubles uh financially, and I started looking for a for a job, and uh, you know, I think it was posted on Stack Overflow Careers, and I was like, what?

I can use my Django and Docker and Python to make Marvel movies?

That's insane.

And uh, I just wanted yeah, to apply the knowledge I had as a software engineer uh into the Visual Facts industry, and for me it was just mind-blowing that I was able to do it.

And you know, when I joined Method Studios, it was a little bit of a shock because I think Visual Facts doesn't have a lot of people from outside the Visual FX world building software, and like it just felt like you know they were not following the best practices and etc.

But they were very open for it, and I think uh you know it did a very it was really awesome and rewarding uh to push the company forward in the software engineering realm.

And I think the same at ILM too, you know, when I joined, I feel there there was a lot of great stuff in place, but there was a lot of great opportunities for improvement, too.

And I think that was the challenge.

Uh, how do we bring this you know iconic 40 years old company to the future with Kubernetes cloud and all the buzzwords, and we we did it, right?

We are running workloads in Kubernetes and the cloud, and uh it's it's just for me has been amazingly rewarding uh being able to contribute to the companies uh while making Visual Facts, right?

Like our product is actually something that I watch uh at night when I go to cinema uh and I enjoy it.

Uh and I can say, hey, I saw this before, or I know who worked on this in the credits, right?

I think it's

It's always always staggers me the number of people that are involved in making, you know, even a half-hour program on you know, whatever.

Like but a full movie, it's just like hundreds and hundreds of things.

Like usually not everybody gets credit.

It's a little bit of a you know, the client offers a certain space, and then you put the people who contribute the most and whatnot.

There's a lot of uncredited people too that are also a crucial part of those movies.

It's an army, it takes an army.

Um, you know, we build a lot of our front ends in React and then use you know Django REST framework for interacting with that.

Um we we don't use Django templates too much.

Um you know uh I I feel like there's some areas that we want to explore on that front.

Like I heard you guys talk about X HTML um a couple episodes ago.

Um so I think that's uh so I think that's just one area we need to explore a bit more.

You know, the deployment, for example, oh, do I need unicorn, I need to know Nginx, I need to like I feel like Flask, for example, makes it very easy to have like a 10-line script that does uh the one function that people needed to do.

And I really love how Django is better is included, and people don't need to think about that.

But almost like I want I would love if Django could also have like a simple mode or something like that that makes it, you know, uh you know, I think maybe in the quick start slash tutorial of the Django page, you could have another one that is like you know, single page application with Django or single Python script application with Django, because you do have that in the docs somewhere.

Uh yeah, I don't know.

I think for that

One is that we we we Django could and should improve the official thing.

And the second is Carlton gave a keynote demonstrating this, and uh I have a package showing actually you know, instead of six lines, it's uh what fifteen lines to to do with Django.

So it's possible, it's just not typically used in that way.

So that's more of a marketing problem I think than anything else.

I just haven't got around to actually putting them on GitHub and then you could uh point the the start project command to them.

But one is single file and the other is single folder because you can that that sort of sync when you start app or start project, sorry, you can just turn that into an app by adding a models file and adding the the name of it to installed apps and it turns into a fully featured app, but you haven't got then the project folder and then the app folder next to it, which is like there seems like an awful lot of files for just one model that I want to create.

Like, why is there so why are there so many files here?

Like and obviously as the project scales, that starts to you know that starts to pay dividends.

But I think there's a lot of room for these kind of two because the other the other example that I that makes me think about this is people doing data science with pandas and you know um pie and all the rest.

And they've just got they've got their data set, they've got their thing, they just want to quickly wham it online and they end up using Flask, which is great.

But from a Django perspective, it's like why aren't you just using Django?

Well, it's because I it's too many files, like ah, we we should have a better story there.

Every time I start Django, it's like, should I name that project the same as that?

Like I always get into that rabbit hole.

It's like

100%.

So even if it was something that was just a switch you could toggle um that had some basic stuff, that you could deploy the um what is it, the polls app, Carlton.

You know, like there is a there is probably a way to to do that, um, or certainly to have something where it's just environment variables and it's just switches debug, secret key, and um allowed hosts, which gets you most of the way there.

I think Django does a great job at saying, like, you know, hey, in production, change this.

Hey, this is not safe for production, but then when you have people just starting off, they're a bit scared and intimidated, like, oh my god, I'm doing my local dive, but none of this is safe for production.

So, like, what am I doing?

Where do I go from here?

And I think maybe just saying the consequences too.

And like, it is okay if your use case, you know, it's simple, you're disconnected from the internet, you're doing some local dive in a data center as a you know, data scientist or visual effects artist.

Like, you know, we are not touching the internet from our data center.

So a lot of it, you know, matters, but doesn't really matter as much as if we were open to the whole world with our uh app.

We're really trying just to you know develop a microservice to help with this workflow thing here uh that could just be a Python script in a server that I SCP and uh you know, write a system did to start.

I I don't know.

I feel there's a lot of potential to simplifying uh and not yeah.

What you know, people want tutorials.

It would be nice to have Django tutorials, but they're a little bit more opinionated than the docs.

So 100%.

And it's anything but it's like half a dozen people giving their spare time, and you know, it's it's not it's not a corporation, it's not a a thing that has capacity to do everything.

So it's a question of what gets done on in the time.

And it's interesting, but yeah, I

I I do think for Visual Facts and Machine Learning and Data Science as well, and uh you know, Django has started recently, or you know, maybe I haven't followed much, sorry.

But uh all the async stuff and doing long running processes, for example, we usually use Django with salary and setting that up and the infrastructure can be a little bit too much.

If there was like a simple thing too that you know, maybe bake all of that in and you know, not performing the salary or scalable, but at least it you could run some async stuff and some sort of queues.

I think you know Fast API has uh class that does that.

I think Tornado has something that does it too, because it's just async.io and Flask.

Uh granted I haven't been following that too much in the Django site, it might already be there, but I think that would

No, I mean Starlet, the the framework which undermines underlies um Fast API, it allows these background thread background tasks where you can just sort of spin it off and go.

And what it doesn't have is like the retries and the you know task acknowledgements and all those kind of extra things, which is when you need a a proper queue.

And yes, celery is the big beast in the room, and it's hard to it's old and scale uh gnarly and whatnot, but it's super powerful if you can get it.

It's a difficult one.

It's a difficult one.

There've been many attempts at uh simple cues.

Um, but yes, that's another one that's always sort of on the list as a as a goodie.

Are you using like groups in Django?

Are you doing it at the API level?

Like how are you uh setting that up if you know?

Um and they usually handle a lot of the authentication.

Um it doesn't uh as Andre mentioned, like a lot of our tools don't touch the internet.

Um and we're a very open studio, so um I I think it depends on the application itself.

Um like for example, that subscription management uh tool I was talking about, our permissions on that are open, so users can log into other users and mess with their settings, but you know, no one does that because it's an internal company and you know we don't hire any trolls that go in and mess with those.

So and having that open atmosphere in our tools um makes it easier for us to debug things, so we can have somebody on our production team help a supervisor and just log into their account and see what's going on, if that makes sense.

There's a really nice third-party package in Django where you can uh log in as any user.

if I had to go.

So you know, um that is a good thing.

But yeah, that enables you an admin, a staff user to log in as another account via a button in the admin, and then you they can just sort of log out of that.

And it and it it that's a bit that's can be really important because you've got a customer who's struggling and they're like, This is what I'm seeing, and you're like, but it works for me.

And to be able to step, you know, with their permission, obviously, step into their account and step through the things and see what's going on.

That can just that can solve it because you're like, no, this doesn't happen, this is fine, this works, silly customer, until you actually do it, and then you're like, Oh, there is a bug, you know, they've they've got an accent over the one of the neck letters in their name, and of course that crashes the app because you know we're we're Anglo-Saxon programs and we never considered that.

Like, you know, any number of problems can come up, but yeah, that that kind of process goes.

I like what you were talking about there, James, about how it's an internal tool, and the the way you can balance what your threat model threat model is not you know hackers on the internet, the threat model is I don't know, we spill coffee on the server.

That's you know, that's a silly example.

But you know, you do you can grade you know what level of protection you put on by what's realistically something that your application needs to handle.

Um we we do we do have some internal checks to keep people from seeing things they're not supposed to, um, because we do compartmentalize, you know, some projects we're working on.

Um but for the most part it's pretty open and that makes debugging very easy.

Um the the software management system we have that allows sim linking also makes it very easy to see what the user is seeing.

Um so if, for example, an artist is working on their own script and they're like, it's not working, can you help me?

It's very easy just to sim link it from their home dirt to my home dirt and pick it up.

So you make some edits, it immediately appears back on there.

That's super.

I mean, you know, like the IDE developers are only just getting to that now.

Yeah.

we're close on time.

We have a lot of openings.

If any of this interests you, please apply.

Uh in find out, apply anyways.

Uh I'm sure our recruiters will get back to you and figure something out.

Work on Star Wars.

Yeah, exactly.

Yeah.

We'll put the link for that in the show notes.

Yeah, no, we will.

We will for sure.

And thank you, I think, Andre, for I think we connected on Twitter.

Someone had put out, I forget, a tweet about Django in the real world, and you said, hey, we're using it over here, and that's how this started.

So Yeah,

Thank you for connecting, too.

Yeah.

No, it's been awesome.

Yeah, it was uh what's the name of the books, Bad?

The Django for Will Will's books?

Yeah.

Yeah, those books were huge help.

So thank you for that.

Yeah, yeah.

I know.

I need to.

There's still not that many resources actually on it.

So yeah, if any companies want to do that, hit me up.

You know, your books are

Sure, but they're next.

They're they're they're followers

And there's other there's other materials, but um generally people write books kind of more at the level they are at, um, whereas to write beginner stuff is less interesting as you progress in your own uh journey.

So yeah,

I just finished his book.

It was great.

Um again, thank you both so much for coming on.

Um we are at DjangoChat.com, chat Django on Twitter.

We'll have notes to everything in the show notes.

So see you everyone next time.

Bye bye.

Bye bye.

Thank you, guys.