Transcript: GeoDjango - Harout Boujakjian and Andrew Hornstra

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Welcome both of you.

Hey guys.

It's nice to be here.

Yeah.

So I'm excited to talk about your app, Pin Planet, because it's a chance to talk about something from prototype to production since you've been working on it for several years, but um hopefully you still remember those early early days.

So maybe we could start with what is PinPlanet and then we'll go from there.

Uh it's a way to keep track of all your travel memories in one place.

So like let's say, for example, that you visit Portugal and you somebody asks you about it later, they want to know your travel recs.

Pin Planet helps you essentially keep track of all of that.

You'll be able to go back and tell them all the spots you visited, like the restaurants, the hotels, museums, etc.

Uh, you keep track of your photos, you have your travel buddies, so it also functions as like a trip planner, and then you get to visualize all of your pins on a uh on a 3D globe as well as a 2D map.

Um, can I ask, what are you using to generate that?

I that's I know that's not Django, but what are you using to generate the globe?

The one in the getting started or the one on the profile now?

Oh.

Because they're two different globes.

That's true.

Tell tell me how they're different.

So the the one in that's in the getting started prompts is our older globe.

It was a web globe that I built in JavaScript using D3.

And then the newer globe takes advantage of Apple's uh map kit.

So they have a way to render 3D Globe.

It's a little bit more performant.

Okay.

So we s we started using that one on the profiles instead of the web one.

Is this

Phew, we're on a Django show.

Go on, tell us about that.

What's the what's the what's the down and dirty though?

Like what's the how do you how do you build such an app?

Because it's quite cool to play with and you know.

We did start as a web app, and we're definitely happy to talk about talk about the PWA aspects as well.

But so the front end is is iOS for right now.

We are in the midst of of building an Android app, and we're actually getting pretty close to releasing it.

The back end is Django and obviously a little bit of Geo Django, and then our database is is Postgres.

We have Redis server running for cache, everything runs on EC2 instances.

So that's good, that's like the quick, quick and dirty.

But so it's literally just the two of you.

We're the engineering team.

Yep.

Yeah.

How's it going building um a Django backend?

Okay, and just you know, a few EC2 instances getting okay, fine, no problem.

Uh a PWA to begin with, okay.

Uh, you know, get that.

Then an iOS app.

Oh, hang on.

How to did uh do two pairs of hands get quite so much done?

It must be a challenge.

Um I'll answer it a little bit.

I think that we we're like a pretty efficient engineering team.

Andrew and I, Andrew and I's skills, we we complement each other really well.

That's my answer, but I want to hear what what Andrew thinks.

Um yeah, especially with with adding ios and we now suddenly we're suddenly uh we're supporting so many different versions of the app.

And with a PWA, it was just one thing.

And it's it's been it's been a bit, but yeah, like Harut said, every time I have an issue, I go to him and he tells me, Oh, you you missed this very obvious thing, or vice versa.

And so we it it works out very well.

So I know Python pretty well, but if I really like want to get into Python details, then I then I go to Andrew.

So I I think this synergy works really well between the

How is that division of labor happening?

Andrew has been taking over the Android app.

I help a little bit over there.

It's pr it's more like it maybe like an 80-20 split.

And then both of us also do backend, handle database stuff, handle server stuff, but that's more I would say Andrew's specialty is backend.

But I'm you know, I'm comfortable getting in there as well.

And since we're in there, like uh Andrew, you've have you been digging into the the whole Kotlin thing in Android or is it still Java based?

Right, brilliant.

Uh the the the titular composition aspect of Jetpack Compose is sometimes it feels inconsistent uh and like a bear to wrestle with, but I'm sure that's a

It's an understatement from the little bits that I've had to help out.

So here's my burning question about Kotlin, since you've been they you go on the Kotlin website, sort of like, you know, a cross-platform, multi-this, multi-that, and then they got this thing down the bottom where it says iOS, and I'm thinking, oh, so is it yet at the case that you're building chunks of your app in it for both iOS and Android in Kotlin?

We're we're sticking with native for both, which is yes, a lot of work.

Because the like you know, and this comes back to the idea of old, you know, PWAs, or why don't you ship ship a PWA and ship it to every platform?

Why go native in the first place?

You know, why why not try and use the cross-platform code then?

Like what does native only give you?

So is it the difference between PWA versus native iOS, or is it something like Kotlin multi-platform, which is saying, all right, you're gonna use one code base to also build iOS and Android?

Because the answers are different.

Because I'm still basically fascinated with the fact that the two of you are building a back end plus multiple front ends, like with just one one pair of hands.

And that's kind of incredible in a way.

It's kind of really hard to do, and to do it at a high quality, you know, that that's a lot of effort.

So I'm I'm kind of trying to tease from you the decisions that lead you to go that that hardest of routes.

So the easier one is the easier way to answer this is why we didn't go call Kotlin multi-platform.

It I think it's mostly it's mostly me.

I just don't believe in in these cross-platform solutions.

They they always they always sell it a lot better than it actually is.

Like you get the first 50% done really well and really fast, but then the second 50%, you're pulling your hair out and you go gray by the end of it.

So that that's that's the reason for that.

The reason we went from PWA to native is because that's more complicated.

Uh we've trained users for 10 plus years, uh, you know, over a decade to look for apps in the app store.

So when you tell them, oh, I built this app, and they're like, oh, okay, what is it called?

Let me look for it in the app store.

And we're like, oh, it's actually not in the app store.

And trying to get over that hurdle is is is very, very difficult.

So that was gigantic.

I think I think the web is the best cross-platform solution.

There's nothing that comes close to like the cross-platform capabilities of the web because every platform essentially has some version of a browser, and that's awesome.

But yeah, Apple in particular does their absolute best to just make that experience not so great.

It's essentially web views with a with a very small native wrapper around it to integrate with the with the iOS.

But essentially all of the views are exactly the same you get on the basecamp website.

Yeah.

I know, okay.

Right, so one more question here, and then I'm gonna let Will have a go.

Because I'm well, I've got you both on the on the hook.

So the big um impedance match for me is the serialization between so you've got your Python backend and you you serialize to I don't know your JSON objects and then you um deserialize into your Swift objects and um or or you know your Kotlin objects or whatever.

So to can you describe how you've how you've dealt with that and what your your pain points have been and you know what what you've enjoyed and what you haven't, and you know, we'll I think follow up there.

But also there's another little switch back to that that Kotlin bit.

Would you reuse the Kotlin bit just for that kind of networking layer?

Or, or you know, is that just it just doesn't bring enough to the table?

I've I've only been using Kotlin for, I guess, three or four months.

Three months or so.

But I've really, really enjoyed Kotlin and have been very impressed by how intuitive the syntax can be.

The library we're using for the client side HTTP is KTOR.

And that's also a server side.

So I I think one of my next projects will be uh a Kotlin server side application just to mess around with that.

Um but for now I think we're just because of the complexity of a two-man team managing four machines, two platforms, uh yeah, we'll we'll we'll stick with just one for now.

I'll I'll answer the serialization piece, which I think is interesting.

It's basically double the amount of work, and there's no way around that.

Like we have our DRF serializers, which you know will serialize and deserialize the data, and we've split that into uh input and output serializers nowadays.

And then in Swift or Kotlin, you know, we have essentially very similar ways to you know, quote unquote serialize the data into Swift and Kotlin objects.

And then you've got the same in Swift with the uh coding, you know, the coding protocol or whatever it's it's called.

But it's again, and they've got lots of utilities, like they know how to map from Python names to Swift names, and okay, great, but it's still rubbish to write those.

And and you spend a lot of time doing that, right?

Uh there's no way around it.

I feel like we bit the billet a while ago, and we're like, yeah, that's that's okay.

It's costly.

I'm glad nothing's changed.

Have they anything there to speed up all of your your work?

So we're trying to send some data to the web view for the old globe.

Uh, and then there was like one line that we got from ChatGPT.

But for the most part, I don't I don't actually ever use ChatGPT.

Uh, but I do uh the the support in PyCharm, I think, if that counts, is pretty good.

It's never given me any code that was something it's never given me any changes, any code I could include.

Um mostly because I've been troubleshooting very complicated problems and the difficulty is almost always at this point with something so mature and like as many files as we have explaining what the problem is.

And if you can do that, you have a pretty good shot at fixing it yourself.

Yeah, yeah by hand.

Um, but I mean, have you tried, was it Py Assistant, right?

That's the new um PyCharm one that they just launched.

I haven't had a chance to play with it myself, but it's sort of like their co-pilot that they just the the new update to to PyCharm.

I didn't like it actually.

I I thought it was kind of it was like a little annoying because some of the suggestions were were just not right.

And it kept doing weird casing.

Like it would give me camel case in Python.

Is that is that the right one?

Yeah, not the underscore, not the uh snake case.

It gave me camel case names.

And I was like, well, why are you doing that?

Like, you know, this is Python.

I like it, you know.

I I'm like um I had a okay, so today I was writing a um a property that maps from choice fields and make sure it's displayed in the right way.

And it's like, okay, I need some tests for it.

So I'm like select it, copilot, I need some tests for this, and it gives me the half a dozen cases, and I don't have to type them out by hand.

I'm like, okay, that's fine.

And the rest of it's you know, not useful, but that little bit saves me a few minutes.

And I so I used to write APIs for a living.

So I back in the day, I used to write iOS apps with the DRF backend, and the bane of my life was this mapping of from serialization to deserialization, and every time it updates and every change, it's like, okay, I've got to make a change in the app to the serializer, change in the DRF backend to the serializer, make sure that that's backwards compatible, or introduce a version to endpoint.

Oh, just it was kind of like the the the the legwork of the of you know, it's not difficult, it's not challenging, it's not it, but it's it's the stuff that needs to be done, the grind work.

And my hope with these toolings is that they can automate that in some way, that they can take away a little bit of the mundanity of that particular mapping task, which it, you know, it's not difficult, but it's time consuming.

We both use PyCharm, and then I also use Xcode, and Andrew, Andrew uses Android Studio.

So it's like kind of it's a little tricky, you know, unfortunately.

And I guess uh part of me is I'm sorry, I'm gonna keep banging the same drum all episode, I realize.

But so this part, the the promise of the Kotlin layer is that if you could incorporate that as a library into your iOS app, that mapping could be done like once in the one layer, but whether or not you can, I don't uh you know, I'm not gonna ask the same question again.

You haven't got that yet.

Well, we've we've uh we dove right into it, but I'm actually curious if we could back up to um how you two met, how like your backgrounds in programming and how it led you to Django, because that's always interesting to hear.

I I know you both, I believe, studied at George Mason University, is that right?

And maybe that's how you met?

Yeah.

Is that how you met as well?

I can I can tackle the question first if you want, just quickly go through my background.

So uh I studied math, uh like applied math and computational mathematics at Mason.

Uh I did a lot of programming.

I actually, surprisingly, I'll say this on the year.

I took AP computer science in high school and I just did horribly.

It was in Java, it was just like the worst experience.

And then I retook the class a couple months later after the AP exam in in college, and it was in Python, and I did much, much better.

And everything just clicked.

I don't know if it was because I didn't like Java or just because Python's a great language, but that was kind of where it started.

And then, you know, as every math major unfortunately goes through, uh, you you do a lot of MATLAB when you're doing kind of computational programming.

This this was, you know, just just a life that I lived for a couple of years.

Then I went back to Python, I did some data science, was a data analyst for a little bit.

And then at some point after that, like it, you know, while doing data science, I started building tools for people.

And this for me was just like the big switch.

When I started building like tools for data scientists, for business analysts, for project managers, I realized, okay, like software engineering is a thing that I really love.

And then and and Python has always been my my go-to choice for for building backends.

I jumped around, I did Flask, I did Fast API, I did Django, and then kind of did the entire rotation again.

I guess Fast API wasn't as big at the time when I first started.

And then I don't know, something about Django just I mean, this is so cliche to say, but like the batteries included aspect, the stability, the maturity of the framework.

I was just like, yeah, this is awesome.

I I'm just going to use this.

And you know, there might be different frameworks, different options, but Chang is quite sweet in its own in its way.

It's quite, you know.

Um it's had all the edges knocked off it over the years, so it fits the whole very well.

All right, Andrew, do you want to?

Sure.

I studied math and physics and didn't do didn't do hardly any programming for a very long time.

I took one computational data science class, CDS 130, did a little bit of MATLAB, did not enjoy it at all, and then said, I I think I'll be able to have a career as a physicist with no programming, very naively.

Uh and both of those things were wrong.

So I didn't end up going and doing grad school.

Um, and later on at uh at Mason, I decided, you know what, I really should learn how to program.

And started with Python again and read through uh Jake VDP's, Jake Vanderplas's, um, amazing whirlwind tour of Python and Python data science handbook.

And those are some of my favorite tools, some of my favorite books that I've read on learning Python.

Love those.

So I read through those, did some automate the boring stuff, and then found my way at a at a bank as an analyst doing work with pandas for about a year, moved on to being an analyst, just doing SQL for eight hours a day for two years, found my way back to working on huge models with terabytes of data in PySpark.

Uh, and then uh eventually Harut and I started working together right after that in a startup doing doing Django.

Uh well I I was doing Django.

Uh and I when when he told me he wanted to do Django for the back end, I was I had a a trip to Chicago planned.

So I was I I got all my stuff together, got on a train, and the train was like 18, 20 hours.

I just did the Django tutorial on the train.

I did the DREV tutorial on the train.

And I think to this day we do about, well, I do about 30% of my code is written on an Amtrak.

So do you do you commute regularly or do you just have to go on special trips to get anything done?

It has to be it.

I I go down to I'm in Arlington now, and I head down to Richmond to see family and friends pretty regularly.

Um and yeah, trains just the perfect, it's the perfect place to work.

Cheaper than an office, probably.

Um it's about 15 hours, but this is pre this is 20 years ago 20 plus years ago.

So I would just read two, three books.

And but there is something, you know, as an adult or as a parent, you know, to Carlton's point to like not be interrupted, you know, train is sort of like daytime, you know, middle of the night, no one's gonna bother you, vibes, which is uh yeah, hard to come by.

And you you cannot leave, you can't distract yourself with something else.

Wi-Fi's too slow to stream, no excuses.

Yeah, yeah.

So you've got nothing.

So so um pin planet, geodata.

So come on, we don't talk enough about GeoDjango, I think, on the show.

It's like probably the best um geo platform, you know, for the web out there, and yet we hardly ever mention it.

So give us your you know, give give us your um experience with Geojo.

Sure.

And we don't have it in Docker, which has led to some frustrations.

Uh it by far the most difficult part was getting it installed, getting everything working, all the correct versions of everything, making sure it's detected, pointing Django at the right set in the settings at the right uh GDOL files and all that stuff.

It's just it's utilities.

Yeah, yeah, yeah.

Brew.

It just things become a gigantic mess.

So at some point, I remember talking to Andrew, I was like, let's just put let's just run GUnic directly on our dev machines, and then and it's just so much faster.

Yeah, so

Yeah.

And it's just the two of you, so you you know you can get away with both figuring out your local dev setup, right?

If you if it was 20 of you, then I think that's where you know the Docker pane is kind of worth it.

Yeah.

How did you baby step your way to you know building pin planet with it?

So the thing the reason why we wanted uh to use Geojo and and really post GIS is because we wanted to be able to automatically capture, like if you pin somewhere from the lat long, we want to know what continent that's in, and then that also extended to what country that's in, so we can run some continent and and country stats like that are that are on the profile.

So we basically we took a bunch of uh JIS data, we put it in, it's about like a hundred megabytes.

I think it's like you could even look it up, it's the coastlines one meter resolution thing.

OSM data.

We we put that in in postJIS, and then every time you pin a place, we run uh an ST con I think it's ST contains, an ST contains query to basically say take this uh point, this lat long point, and then tell us like which of these countries it's in and then which continent it's in.

So that that's like the extent of our current postJIS use, but we want to extend that to cities as well, so we can also start capturing some city data.

That's very nice to not have to write some uh raw queries and be able to do that.

It's really convenient to be able to just slightly extend the ORM with the Geojle extension.

Uh that's it gives me a lot more confidence about having that work in the future.

Uh but

Yeah.

Yeah.

So we have to re-import it every time you recreate the database.

So it's a little bit of a testing, like there's some hassle there.

Thank you for saying that.

Oh, I'll find I'll look it up when we're offline and I'll I'll see if I can find

um search.

Can I ask what what are you using to power that?

How how is it building out search?

Because that's that's a non-trivial thing too.

Uh I guess once I was all logged in, there was a play for a place set where you've been.

I I I believe I I typed in Yeah, I typed in zip code or I typed in the name.

So this is really useful.

Um and then we're also we're actually also using Apple Maps, but they're server APIs for Android to have a consistent search experience.

functionality with that.

With an awful idea.

Use something that's already out there, but

And then I think you got a terabyte of data to host, you're gonna have to do caching and all this stuff.

So I

It's like, ooh, like this big I think that's a universal feeling.

No, it's like we want to do this ourselves because clearly we'll do better than what's available, but can we?

We had considered setting up Elasticsearch, but there were there, I guess it's the prioritization is the real answer for for why we haven't done that.

We want to, we want to improve search.

To a separate thing.

I'd set up Trigram search as well, and we just couldn't get the results to be to feel good when you're like actually searching it.

So we'd always type in some really comp people are gonna look for London, right?

Or New York, and you can get one to work well and one to just not work well at all.

And yeah, we we gave up, and I contains just it works really well.

It gives you what you expect.

I mean, I think there was something like I was I added in like DjangoCon US, and I typed in Durham, and you know, just Durham, and the default was in the in the UK, which makes sense, but then I just added you know NC.

Um I mean it was yeah, it will it was more than sufficient in searches, you know, everyone compares you to Google, so it is sort of like it it it asymptopes pretty quickly on the results unless you're building a search engine yourself.

Um anyways, okay.

That was that was one thing I wanted to ask about.

Can we can we talk about the PWA?

How did you so what what actually was the PWA?

What was that setup?

So uh the the way that this initially happened and uh was my girlfriend who I this is the maybe the one beginning portion of the story that we didn't talk about.

So this idea came from my girlfriend wanting to pin all the places she had been to.

And this started in uh November 2021.

So at the time, because I had done so much web development and I was working at a company where it almost felt like I was at an agency, I was just constantly building new projects.

I said, all right, let me see if I can take what you want, which is an app, and build it on the web.

And that's where the the kind of the PWA came up.

I I realized like, oh, okay, you can actually add stuff, you can save it directly to your home screen, it'll function like an app.

So I ended up writing tons and tons of JavaScript, which I'll say this on the air.

I I like JavaScript, I don't have an issue with it.

Uh I don't think it's a better language than Python.

So but in in any case, uh I I built the initial versions of it as a web app.

And we even promoted it pretty heavily as a web app.

Like, you know, got a bunch of people to install it, and then about three months into it, Andrew and I uh uh started working together on it as well because a one-person engineering team for such a big project just doesn't work.

And and now I can't imagine, I I I can't even remember what it was like to work on this without Andrew also being here.

But we had we had uh a web app.

Obviously, the the constraints that I talked about at the beginning of the episode, which is like finding web apps in the app store don't that functionality doesn't exist, push notifications don't exist, Apple makes the experience not so great.

We bit the bullet and said, all right, we should probably just go native.

So you gotta you gotta go to where they are.

Like you'd never find Pin Planet by browsing, right?

You'd never find you know some other indie app by browsing.

So it's you've got to do the same amount of marketing.

And if you get the keywords right, you can actually for rank for stuff, which is somewhat surprising.

The the trickiest part is actually thinking like, well, you know, this kind of app isn't like the norm.

You know, Instagram is the norm nowadays.

Like if you think about all right, I want to upload my photo somewhere or social media stuff, you think of that.

But pinning all the places you've been to isn't something that people are always thinking about.

So one of the hardest parts of this project is actually thinking, like, all right, well, what would a user potentially type in to find the kind of thing that we've created?

I mean, one I don't know if you thought of this angle.

One uh I'm I'm familiar with families that have like a family, you know, map, right?

And then they pin like where the family has gone or like, you know, different colors, like if somebody for big so I don't know if the family angle plays into it at all.

I would think it's more like the 20-something backpacking crowd would be like the default, but there's also um yeah, I don't know.

A number of families I know have that big thing, and uh we're always like, oh, we should we should have that, but we don't have a wall that would work for it.

But yeah, yeah, it's a tricky thing, I guess.

Well, you know, that's that's why there's business problems separate from tech problems, I guess, right?

So I so in that case, then I I guess it's that journey.

It's like how are you finding scaling?

You I mean you're obviously coping, but there comes a point in which you know you're gonna need a third pair of pants and a fourth now to keep growing.

Because uh Anna on the other end, who's our our third co-founder, she's kind of alone in that regard.

Like I help, I try to help out as much as I can with marketing, but that's obviously not I'm not amazing at it.

Although I have been putting together TikTok videos, which is is another story.

But um, yeah, we would we would hire we'd hire a marketing person, and Andrew and I would just continue to work together.

It's not fair to her, because like if we got if we got another engineer and she's like still alone doing all the marketing and and stuff by herself, you know.

Yeah, no, I get it.

But you feel like so, but in the flip side of that, it you you must feel like you're not drowning, you know, you're you're you're doing fine.

You're you're running the servers, you're running the back end, you're building the front-end platform, the front-end applications.

You seem to be handling that very well.

We've we put a lot of time into our testing.

We didn't start out with testing, uh, we kind of we added it several months in, and that was a that was a big dedicated effort where we said we want to just we want to test, I think we just did all of our views.

Yeah.

We've got like 93% coverage.

I think we checked recently, we have almost 500 assert statements.

I mean, yeah.

The other half actually is we we spent a considerable amount of time like getting using Ansible, like writing a writing our own playbook so that we can spin stuff up if we ever need to, which actually has happened multiple times.

We're like, you know, I I can't even I can't I wish I could remember a good one to to say or like a good reason why we brought down one of our servers and then we brought it back up like within just a couple minutes.

I think it was Redis.

I think we had done something with our Redis server, and then we decided, like, all right, you know what, this this is not working.

We want to upgrade to a larger server.

We just brought that one down and brought the new one up, and like it was so fast, and it gives you so much confidence to know that okay, even if something happens to the API server, we'll create a new server, uh new EC2 server, and then we'll run Ansible and and we're good.

And that really, really does give you a lot of comfort.

Or I I've I believe I read somewhere you were Heroku at one point, or did you always go EC2?

We've we've always been always EC2 and EC2.

Yeah.

And I assume that's because you both have prior experience in work settings using EC2, or you just jumped right to EC2 just because that's what the big kids do.

Yes, we both have uh experience with with EC2.

I used to work at a company where uh you could like just go to an internal website and provision a new Linux server.

So for me, and then that was like the easiest way to basically set stuff up.

So both of us have have a lot of experience like running stuff directly on Linux.

And I I don't know, I guess maybe we just find that it's easier.

We get a machine, I can SSH into it, I can do what I want.

That's to me, that's simpler.

So uh yeah, that's why we stuck with easy term.

When newer, younger, uh junior engineers say, like, oh, well, how should we go about deploying this?

I never recommend AWS, I never recommend an EC2 instance, I never recommend anything Linux.

I'm like, use a PaaS, it's so much easier.

You have Heroku, you have Fly, there's a bunch of them.

It makes it so, so much easier.

Because I think the unfortunate thing is like it can be really scary.

And when you're new to programming and deployment and you see all the work you have to put in, you're like, oh man, this is what I gotta go through.

It's like, wow, all of that.

So I want to dig into your testing.

So you're testing the Django, your Django application, mainly with kind of with the view test, the API client or the test client and testing sort of the view interface.

Yeah, yeah.

Yep.

Is that right?

Yeah.

And then I imagine you've got, you know, if you've got special model methods or whatever, you might have a particular unit test to cover that because you know, helps you write the thing, if nothing else.

What about testing against the front-end application?

So how do you how do you test your iOS app or your Android Android app?

The the problem with the front end is it's so dynamic, not in terms like it's dynamic in terms of how frequently things are changing.

And unfortunately, there just this is probably the point where the two-person team breaks down a little bit.

We just don't have the manpower to say, all right, let's go through and do the same amount of testing for our front end.

More frequently than I think we'd catch anything breaking, because things haven't really been breaking too much.

you get off the show.

Yeah, exactly.

And coming, both of us have written, uh obviously use Python and JavaScript, which are super dynamic, but the type languages can actually save you from a lot of these really little mistakes.

And man, I really like it.

I still enjoy writing that uh more, but it's it has not been an impediment for writing Kotlin.

It it's forced me to think more about what I'm uh what I'm writing and and code reusability.

Uh, but yeah, I've it's been very a very nice feature, not in my way at all, surprisingly.

Yeah.

And so far they haven't weighed in, which because there is obviously the trade-off for beginners if you say, okay, it just raises the bar a bit more.

And yet I would say the majority of projects at scale seem to use some s sort of typing with with Python because yeah, it saves you time in the long run.

And I I I follow the issue and I'm like, oh my god, I really hope to get to this soon, but I don't know.

But we do we actually use type hints for everything that's not Django in Python.

Everything we've written, I think.

Yeah, like

Like you do in the channel.

The problem is I installed MyPy and then it complained that all of the Django stuff isn't type, so it's yeah.

It's like I'm here for a day and I'm I'm still getting a thousand errors, and I maybe I'm not clever enough to work out all the config options, but uh surely there might there should be a MyPy progressive command that just sort of says, look, we'll start off with this one.

Can you fix this one?

But that doesn't exist.

I mean, I'm sure there are, but you know, just like speeding up your tests or caching, like are there anything that come to mind?

Because I find those are always interesting to hear what what what pops up as you scale?

rough tests, and I think S3 right now is littered with a bunch of test images.

A million of those.

We couldn't get file system storage to work in testing after the 4.2 upgrade.

And we followed the issue, and some people had very similar issues, but not exactly.

And then I don't know what we did.

It works now.

I think it's like prioritizing how it gets storage, it gets the the proper storage.

I don't recall exactly what it was, but it it it fixed it, it works now.

Uh but we talked about earlier for performance for testing.

We tried parallelizing it, which worked really well until we needed to load in all that OSM uh coastline data.

For our Explore page, when you first click it open and you get all of the people's pins, uh we have a monster uh SQL query for that.

Uh we don't have any, there's no machine learning just yet.

We had considered putting it in, but uh again, perks of a two-person team, it's it's a little too much effort.

Um but that was taking multiple seconds.

It was taking maybe one or two seconds in dev.

And then I ran it in prod and it was like multiple seconds, and then I told Andrew, I was like, okay, we have we have an issue, and then

ts, a lot of over windows and partition.

This is all ORM by the way, which has been very been very nice.

Uh and we managed to cut it down to what like 150-200 milliseconds?

So the simplest solution cut out a ton of our actual query time where we just went in and we're not gonna want to present, you know, in the explorer things without images.

Right?

It's gonna be a boring thing to look at, and they're not gonna get to it anyway.

No one's gonna scroll to 4,000 uh.

Like there's so much data is coming.

We basically aggregate our entire database, and we're wondering why, like, oh man, why is this so slow?

Yeah, good.

It's like when you cut that.

It's often the case, like people are like, oh, why is it or Django slow?

Or no, your query is slow.

Let's fix your query and we fix the problem, right?

I think you was that Yes, yeah,

I haven't I was using I'm using that on a on a project.

Um I wanted a I it's just a little field that lets you um pick um upload an image but and pick a point of interest, uh you know, a place in the image to sort of be the focal point if you in case it gets cropped.

And I wanted that for avatar images.

You know, you upload an image, you want to crop it round, and you want to say, look, that's this that's that's the bridge of my nose there.

So that's the point of my nose.

Um and there are various options, and but I I wanted for for various reasons I wanted to use that one because it's mainly because it's less code.

I don't I don't think I've I haven't heard of that one.

Yeah, well, we can look into that.

Well, you just uh to talk a little bit.

Me too, sometimes.

Yeah, yeah.

Maybe I prefer the podcast over over reading.

I don't I don't know what it is.

Every time I see a podcast episode, I'm like, oh boy, here we go.

Oh, but that's how I that's how I stay up to date with all the stuff in in Django.

For real though, people are surprised, like, like, how do you know all this stuff about Django?

And I'm like, there's an amazing podcast.

You know, and it it really does help.

Yeah.

Yeah.

But I know that not everyone is following every single thing that I do.

So um, I need to that's good to hear.

Uh our problems with images actually weren't even in Django, they were client side because when you are uploading images straight from your phone, we're talking, I mean, nowadays, like five to ten megapixel images are not it's not out of the norm.

Multiply that by potentially 10, 20, 30.

Like if you add photo dump images to your place, plus you add images to each of your spots.

That's like I remember the first time I had Anna pin something, it took over a minute and she had like five or six images.

And I thought, that's a problem.

So we actually have to handle compression on the front end and resizing before we can even send it.

And so you you will actually crop the image on the client before send uploading or yeah.

We we so we don't crop, but we do we do resize and we add a very light amount of compression to bring it around 500 kb, and then that makes the request significantly faster.

So you'd no point having outside of that.

Yeah, you've got a bunch of different screen sizes, but versus you know, if you're developing for desktop web, I don't have to support and care about a 34-inch monitor.

Yeah, and and the 21-inch monitor at the same time.

And the the the angry user who uploaded that panoramic page show that

Yeah, yeah, yeah.

Yeah.

Are there can you tell us um like what's next for Pin Planet, right?

Like you have obviously an Android app coming.

Are there any new new things you're excited about uh working on related to it?

We have tons and tons of people that are asking about asking about it on Android.

And uh I I guess now hopefully I'm not sure when the podcast will come out, but I imagine the Android app will be out uh either before then or very close.

Uh the other kind of cool thing that we're we're doing is uh we're building a version of Pin Planet for the Vision Pro, the Apple Vision Pro.

And hopefully that will be coming out.

We put a video out, uh like a short snippet out on YouTube and we post it on our socials and stuff, and and people seem to there seems to be a little bit of interest there.

I can't afford the Vision Pro goggles, but I can build for them.

It would you show that to me.

It looks it looks really cool.

Yeah.

Oh, we're on iPad too.

Pin Planet does actually also work on iPad.

Oh.

Uh most of the work was figuring out how to automatically resize images based on the width.

And then once I figured that out, it actually turned out to be not super difficult to do.

No, once once we figured out how to resize images automatically, that that was like the big thing.

And then iPad handles uh you can do uh iPhone does it as well, but on iPad it's a bigger deal for dynamic type.

And once we kind of constrained our dynamic type to not be like super gigantic text, like one letter is the size of like half the screen.

If you constrain it a little bit, then you have you have an app that works on iPod pretty easily.

Some devices won't even honor uh your contracts for certain events, like if you tell them you can only pick this many images, some devices just will say, we'll pick as many as we want.

So that that I'm worried about.

But we'll cross the website.

Or maybe not.

I don't actually I don't know.

Well, from whatever publicly available data we've got.

Yeah, and and that's what we're targeting.

Right.

Yeah.

Yeah.

If it's it doesn't sound it's a big enough issue, so I want to let you know.

Yeah.

Yeah.

It was like very much like you know, on the i the iOS devices, so it was not too hard to customize them, and then there was a w a sea of different Android options, and you had to just pick the ones you had the sort of capacity to support, basically.

So like when you have like pixels are amazing, Samsung, higher-end Samsung devices are amazing, like those are the easiest to support, but then you have these random uh I actually I guess not random, they're probably hugely uh popular devices in countries like India or uh China or Bangladesh.

And it's like all right, these these are a little bit hard to support because they're they're a lot less expensive, but they're way less powerful.

So you need an app that can also work hopefully 80% as well on on the lower end devices, you know, the ones that aren't quite as powerful.

So it's it's tricky to that's a tricky portion to balance, in my opinion.

And can I make this can I make the app efficient so that it will run on a lower end device?

I think we have the same problem with websites, right?

If you load all the JavaScript in the world, your your website won't run on a lot of people's phones.

Well, okay, let's see if we can keep it a bit lighter so we're more open to everybody.

That's cool.

If you had a magic wand, and you don't have to just say Django, but if you had a magic wand, what would you fix?

I'll let you both have an answer if you want.

I I have I have two answers.

The first one would be I'd love to have typing in Django.

That would be one.

I would want um rest framework and channels to be a part of core because, in my opinion, I think this is hurting the marketing of Django.

And this is coming from someone who has done a lot of like JavaScript.

I love JavaScript, I do a lot of front-end work.

And I also love Django.

It's like my go-to framework of choice for anything I do in the back end.

But unfortunately, like we as a community are competing with VC-backed JavaScript frameworks like Next.

And we we need to, I think not having like API support at the very least in core makes it look like Django is a framework that only does, you know, uh like old server-rendered HTML templates.

When actually you can build very robust, stable APIs with with Django and also WebSocket support.

I so that would that would be mine.

I think more for the benefit of the community.

Okay.

Good.

Uh I I ran into some issues with like the granularity of throttling.

Uh and you know, we wanted to restrict more of our writes versus our reads, um, and kind of ran into some we had to we had to make a more custom solution for that.

Uh but the the the biggest thing that's actually cost me the most time had been the ORM is very nice.

I use it a lot.

I almost exclusively use the ORM in in uh Pen Planet, some exceptions for our analytics dashboard.

Uh but and I I understand that it's trying to be SQL backend agnostic with the language that it uses for some of its methods.

But man sometimes I feel like there's such a disconnect between the operations you do on the in the ORM and what's actually happening in the sequel.

And I'm very much a SQL person.

I have a lot of experience with it and I can appreciate not wanting to require that kind of experience for uh you know the new developer.

But sometimes it feels like there's there's gotta be some middle ground where you can more closely reflect the SQL standard versus an abstract ORM of its own design without sacrificing the accessibility to new developers.

It makes it easier to come back to after a while if you're working on Kotlin for a bit and you've written SQL and you come back to Django and you're like, all right, what what do these keywords mean?

What's actually happening?

When does it allow me to not get the ID in this instance versus requiring me to include the ID.

Yeah.

Yeah yeah yeah

yeah yeah yeah no I get you.

um in our discussion um so obviously people can go in the app store and maybe the Android store we'll put a link if by the time it comes out for Pin Planet um are there other ways people should stay in touch?

You know if you if you use the app leave us a leave us a rating of the apps for that does actually help out significantly yeah and then other than that I I don't think there's anything else.

I mean it's been a really fun journey uh I just want to emphasize again that like Django is a it is just a phenomenal back end framework and it is boring and that's amazing.

It's mature it's stable it stays out of the way you know that it's working it you know when you have to deal with all the other complexities of of building an app it's nice when you don't have to pour it about one portion of it.

You know that okay this just works and and that's that's awesome.

thank you thank you very much yeah