Transcript: GeoDjango - Harout Boujakjian and Andrew Hornstra

Hi, welcome to another episode of Django Chat.

I'm Will Vincent, joined by Carlton Gibson.

Hi, Carlton.

Hello, Will.

And we're very pleased to welcome Harut and Andrew from PinPlanet.

Welcome, both of you.

Hello.

Hey, guys.

It's nice to be here.

Yeah.

Yeah, thank you for joining us.

So I'm excited to talk about your app, PinPlanet, because it's a chance to talk about something

from prototype to production, since you've been working on it for several years.

But hopefully you still remember those early, early days.

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

Okay.

So pin planet is an app that lets you pin where you've been.

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 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, et cetera.

You can 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 that was one of the things

that's most striking when i first signed up for it is that that 3d globe um can i ask what are

you using to generate that that's i know that's not django but what are you using to generate the

globe oh so i have to ask which which globe are you talking about the one in the getting started

or the one on the profile now?

Oh.

Because they're two different globes.

That's true.

Either.

Tell me how they're different.

I can answer both.

The one 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 map kit.

So they have a way to render a 3D globe.

It's a little bit more performant.

So we started using that one on the profiles

instead of the web one.

Okay, very cool.

Okay, and the back end is using GeoDjango.

Is this?

Yeah, yeah, there we are.

Yeah, all right, good.

We're on a Django show.

Go on, tell us about that.

What's the down and dirties there?

How do you build such an app?

Because it's quite cool to play with.

Okay, so the front end is completely native.

We did start as a web app,

and we're definitely happy to talk about the PWA aspects as well.

So the front end is iOS for right now.

We are in the midst 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 GeoDjango,

and then our database is Postgres.

We have Redis server running for cache.

Everything runs on EC2 instances.

So that's like the quick and dirty.

Right, so brilliant.

So it's literally just the two of you?

Yes, we are.

We're the engineering team.

Yeah.

Okay. So here's what I want to know. How's it going building a Django backend? Okay. And just, you know, if you read C2 instances, okay, fine. No problem. A PWA to begin with. Okay. You know, get that. Then an iOS app. Oh, hang on. And then an Android. How do two pairs of hands get quite so much done? It must be a challenge.

I don't even know how to answer that.

I'll answer it a little bit.

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

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

That's my answer.

But I want to hear what Andrew thinks.

It's about as hectic as you kind of made it seem and sound.

Yeah, especially with adding iOS.

And we now suddenly we're supporting so many different versions of the app.

And with a PWA, it was just one thing.

And 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 missed this very obvious thing or vice versa.

And so it works out very well.

And let me just say on the air that Andrew is my Python guy.

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

So I think this synergy works really well between us.

So now who, yeah, I was going to say, so iOS, are you both writing Swift or are you dividing that versus, you know, Java for Android?

How is that division of labor happening?

So, no, I do iOS fully.

Andrew has been taking over the Android app.

I help a little bit over there.

it's it's more like it maybe like an 80 20 split and then both of us also do back end handle

database stuff handle server stuff but that's more i would say andrew's specialty is back in

but i'm you know i'm comfortable getting in there as well okay and since we're in that like andrew

have you been digging into the the whole kotlin thing in android or is it still java based we're

we're 100 kotlin and jetpack compose right brilliant and so um for the listeners like

jetpack compose is a bit like swift ui it's one of these declarative ui frameworks so you can just

sort of spell it out and then the runtime works out how to render it and so you're not it's

simpler and quicker i guess yes simpler in syntax uh the the the titular composition aspect of

chipback compose is sometimes it feels inconsistent uh and like a bear to wrestle with

but i'm sure that's a personal fail it's an understatement from the little bits that i

have to help out so the essential complexity of ui design didn't just disappear somewhere

ah you know it didn't right okay so here's my burning question about kotlin since you've been

doing it you go on the kotlin website so like you know a cross-platform multi this multi that and

then they got this thing down the bottom it says ios i think oh so is it yet at the case that you're

building chunks of your app in it for both ios and android in cockney not we're not doing that

and we're not going to go in that direction we're we're sticking with native for both which is

yes a lot of work um okay so can i ask why because the like you know and this comes back to the idea

or, you know, PWAs, or why don't you ship a PWA and ship it to every platform?

Why go native in the first place?

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

Like, what does native only give you?

Well, it depends what exactly you're asking for.

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 going to use one code base to also build iOS and Android?

Because the answers are different.

Right, no, but it kind of is both, right?

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 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's a lot of effort.

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

Okay.

All right.

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

I think it's mostly me.

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

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

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's the reason for that.

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

We've trained users for 10 plus years, 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 very, very difficult.

That and notifications.

Yeah, that and push notifications.

Yeah, that was gigantic.

There's a lot of people in the web world who are kind of cross with the way that PWAs just aren't as capable as native apps.

It's really unfortunate because like two years ago, I was such a huge advocate of the web.

And I still love the web.

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.

I mean, I think the Basecamp app is like that, right?

It's essentially web views with a very small native wrapper around it

to integrate with the iOS.

But essentially all of the views are exactly the same

you get on the Basecamp website.

Yeah.

I don't know.

Okay.

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

because, well, you're both on the hook.

So the big impedance match for me is the serialization between.

So you've got your Python backend and you serialize to, I don't know,

your JSON objects and then you deserialize into your Swift objects

or your Kotlin objects or whatever.

So can you describe how you've dealt with that

and what your pain points have been and what you've enjoyed

and what you haven't?

And we'll, I think, follow up there.

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

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

Or, you know, it just doesn't bring enough to the table.

Yeah, I can speak to the Kotlin aspect of that.

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

Three months or so.

Well, it's remarkable that you've been able to build the app in three months.

It's been a lot of work.

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 think one of my next projects will be a Kotlin server-side application just to mess around with that.

But for now, I think we're – just because of the complexity of a two-man team managing four machines, two platforms, yeah.

We'll stick with just one for now.

And let me answer –

Yeah, I'll just chase –

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 will serialize and deserialize the data.

And we've slipped that into input and output serializers nowadays.

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

But you end up writing a set of kind of almost boilerplate-y classes in Python.

And it doesn't matter if you're using DRF serializers or, you know, Pydandic or Atas and Katas.

Like, it's still boilerplate.

It's still rubbish to write.

And then you've got the same in Swift with the coding, you know, the coding protocol or whatever 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 you spend a lot of time doing that, right?

Yeah, yeah.

There's no way around it.

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

It's cost.

Okay, so good.

I'm glad nothing's changed.

But what about LLMs and CodePilot and these things?

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

I think we used ChatGPT one time a while ago, probably six or seven months ago, and it helped.

Yeah, there was some weird WebView layer we were doing.

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

And then there was like one line that we got from ChatGPT.

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

But the support in PyCharm, I think, if that counts, is pretty good.

Actually, I can say that I've used ChatGPT a few more times.

It's never given me any code that was something.

It's never given me any changes, any code I could include.

mostly because i've been troubleshooting very complicated problems and the difficulties 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 of fixing it yourself so you're still

essentially the the bottom line is you're still when it comes to the serialization

deserialization you're still sort of having to maintain that mapping layer you know yeah yeah

my hand yeah okay have either of you we um we recently had simon willison on um who's a obviously

big advocate of loms um but i mean have you tried was it pie assistant right that's the new um pie

charm 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 new update to to pie charm i i did recently try it i didn't

like it actually i thought it was kind of it was like a little annoying because some of the

suggestions 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 why are you doing that like you know this is python so carlton you like

copilot though right you yeah no but i like it for these kind of boilerplatey things and i like it

you know 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 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 back in 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.

Just, it was kind of like the legwork of the, you know,

it's not difficult, it's not challenging, it's not,

but 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

that particular mapping task which it you know it's not difficult but it's time consuming i think

the direct integration entirety ease is going to be the biggest the biggest value add for

i mean this is a very obvious thing to say but for developers just because

swapping back and forth between windows copying and pasting waiting for the output there and

just the amount of tasks switching it's it is a higher cost to your productivity than

i think either of us were willing to willing to take to fit that into our workflow the other the

other kind of issue is that we're both of us are jumping between two ids 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 yeah and i guess part of me's i'm sorry i'm gonna keep banging

in the same drum roll episode, I realize.

But so this part, 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 it can, I don't know.

You know, I'm not going to ask the same question again.

You haven't got that yet.

All right, well, we dove right into it,

but I'm actually curious if we could back up

to how you two met,

like your backgrounds in programming

and how it led you to Django,

Because that's always interesting to hear.

I know you both, I believe, studied at George Mason University.

Is that right?

And maybe that's how you met.

Is that how you met as well?

We met through a friend that I guess also went to Mason.

And then we've been working together ever since.

I can tackle the question first if you want.

Just quickly go through my background.

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

I did a lot of programming.

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

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 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, you do a lot of MATLAB when you're doing kind of computational programming.

This was 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, while doing data science, I started building tools for

people.

And this for me was just like the big switch.

When I started building tools for data scientists, for business analysts, for project managers,

I realized, OK, software engineering is a thing that I really love.

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

I jumped around, I did Flask, I did FastAPI, I did Django,

and I kind of did the entire rotation again.

I guess FastAPI 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 the batteries included aspect,

the stability, the maturity of the framework,

I was just like, yeah, this is awesome.

I'm just going to use this.

that that response like it's the look on your face as you said it's like

somehow it's like when you're building an application it just sort of gets out of your way

and you know there might be different frameworks different options but

jenga 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

yeah all right andrew you want to sure and so also went to mason i studied math and physics

and 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 think I'll be able to have a career as a physicist with no programming, very naively.

And both of those things were wrong.

so i didn't end up going and doing grad school and later on at at mason i decided you know what

i really should learn how to program and started with python again and read through jake vdp's

jake vanderplasse's amazing whirlwind tour of python in python data science handbook and

those are some of my favorite tools or 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 pi spark

and then eventually harut and i started working together right after that in a startup doing

doing django well i i was doing django and i when when he told me he wanted to do

Django for the backend. I was, I had a trip to Chicago planned. So I was, 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 DRF 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. Super. Do you commute regularly or do you just

have to go on special trips to get anything done oh man it's it's got to be both 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 train's just the perfect it's the perfect place to work

cheaper than an office probably cheaper than co-working yeah

back when i was in college i went to william and mary for undergrad and i would go up to boston

which is almost as long as it can go um it's about 15 hours but this is pre this is 20 years

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 it's great and you you cannot leave you can't distract yourself with something else

wi-fi is too slow to stream right no excuses yeah so just don't like just don't download the um

the series before you've got nothing so so pin planet geodata so come on we don't talk enough

about geodango 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 a you know give give us your um

experience with geodango and you know do you want to talk about sure geodango on mac os is our

current setup for local dev 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 gdoll files and all that stuff it's just it's utilities it's fair to say

that we still have nightmares about gdoll and proj insulation yeah yeah yeah and absolutely

brew yeah and brew brew doesn't help in this case it just things become a gigantic mess

if there was a docker image to end all images would that help or no because we used to work

in docker but honestly at some point i i just got annoyed with like having to remount and then the

the container cache is maybe sometimes a little too strong so you have to rebuild the entire

container setup and then it just ruins your flow so at some point i remember talking to andrew i

was like let's just put let's just run g unicorn directly on our dev machines and then and it's

just so much faster if you can't tell we're really into doing things that do not scale

yeah so that's just well they scale eventually yeah and it's just the two of you so 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

the maybe these are the perks of a two-person team currently i think so yes yeah but anyways

yeah so yeah um so once it's installed though what was i mean there so there's obviously jango

project docs but like how did you how do you learn that how did you baby step your way to

you know building pin planet with it so the well let's let's talk about our use case first so the

The reason why we wanted to use GeoDjango 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 country stats that are on the profile.

So we basically took a bunch of GIS data.

We put it in.

It's about, like, 100 megabytes.

I think it's, like, you could even look it up.

It's the coastlines one meter resolution thing.

Yeah, with some data.

Yeah.

We put that in PostGIS, and then every time you pin a place, we run an ST.

I think it's ST contains.

An ST contains query to basically say, take this point, this lat long point,

and then tell us which of these countries it's in and then which continent it's in.

So that's the extent of our current PostGIS use,

but we want to extend that to cities as well

so we can also start capturing some city data.

I think, yeah, the extent to what we use GeoDjango for is that SD contains.

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

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

It gives me a lot more confidence about having that work in the future.

Yeah, you're not gonna write to yourself. Yeah. Yeah, and it's it I guess

The biggest issue we've run into has been

when we tried to parallelize testing outside of installation when we try to parallelize testing because we

Like

recreating that database

With all of the other dip, you know geo data in it was was a bit of a pain

Because you need, this is one of the cases where you need the 100 megabytes of your GIS data in the database, even if you recreate it.

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

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

Yeah, I'm wondering if there's some clever snapshotting, DB snapshotting technique you could use,

where you just sort of swap in a snapshot and go bam, and then speed that up.

But I haven't got one to hand.

If you find one, send it our way, because that would make our testing much faster and easier.

It does give me an idea, though.

Thank you for saying that.

I'm sure there's some Postgres thing that does that.

I'll look it up when we're offline.

I'll see if I can find it.

Search.

So I had fun playing around with your search.

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

How is it building out search?

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

What's search?

Well, like when I typed in just zip code for a place.

For example, I guess once I was all logged in,

there was a place where you've been.

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

For our search, we use Apple Maps.

And thankfully in Swift, they actually have a way to just,

you could just start typing stuff in and they send the request for you.

So this is really useful.

And then we're actually also using Apple Maps,

but they're server APIs for Android to have a consistent search experience.

been for a while I've been for a little while trying to convince Harut to make

our worst decision yet which is to take the subterabyte of OSM data out there

loaded into a post GIS instance and host our own search functionality with that

with awful idea use something that's already out there but the worst part is

that when you're two engineers and both of you guys know like how to do stuff

like this and you're excited by big tasks like I'm sometimes like well maybe

maybe we should do that 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 we'll look at our issues list and decide yeah

that's a good procrastination thing it's like oh like this big i think that's a universal feeling

this is every engineering decision ever yeah ever writ large no it's like we want to do this

ourselves because clearly we'll do better than what's available but can we yeah it's all about

the journey anyways so for the place search so like if you go back to the explore page and you

start typing stuff in that one actually is i think it's just an eye contains right now we had

considered setting up elastic search 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 it's actually

and then you'd explore postgres search before going all the way to elastic right to a separate

i'd set up a full text search uh set up for for that functionality and tweaking it it it wasn't

great 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 people are

we're gonna look for London, right, or New York.

And you could get one to work well

and one to just not work well at all.

at all. And yeah, we, we gave up and I contains just, it works really well. It gives you what

you expect. That's my favorite story. Yeah, it wasn't, it wasn't an issue. I mean, I think there

was something like I was, I added in like Django con 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, you know, it w it was more than sufficient and searches, you know,

everyone compares you to to google so it is sort of like it it asymptotes 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 set up okay yeah so the the way that this initially happened

and uh was my girlfriend who i this is 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 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 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 started working together on it as well because a one-person engineering team for such a big project just doesn't work.

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

But we had a web app.

Obviously, the constraints that I talked about at the beginning of the episode, which is like finding web apps in the app store that functionally 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 hard to convince the users to to come to you especially when you have so little

visibility so you gotta you gotta go to where they are yes but like the visibility in the app

store is not great unless you're like one of the chosen five apps they put on the you know the

home page there like you'd never find pin planet by browsing like you'd never find you know some

other indie app by browsing so it's you gotta do the same amount of marketing well so the the cool

thing actually is that similar to seo there is aso which is app store optimization and if you

get the keywords right you can actually rank for stuff which is somewhat surprising it's a huge

increase in signups from yeah one keyword tweak yeah we we did like we've done small keyword

tweaks here and there to see 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?

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

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, yeah, I don't know, a number of families I know have that big thing.

And 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 why there's business problems

separate from tech problems, I guess, right?

Yeah.

Carlton, you have a question?

Oh, good.

Yeah, no.

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

It's like, how are you finding scaling?

I mean, you're obviously coping,

but there comes a point in which, you know,

you're going to need a third pair of pants

and a fourth to keep growing.

Yeah, I think right now that if we were

to bring on another person,

we'd probably bring on someone that does more marketing

honestly because anna on the other end who's 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 stuff by herself you know yeah no i get it i

get it but you feel like so but in the flip side of that you you must feel like you're not drowning

you're like you know you're doing fine 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 built we've spent a lot of time and put quite a bit of effort into building out that

kind of supporting tech infrastructure we've yeah we put a lot of time into our testing we didn't

start out with testing 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 and we've just maintained that coverage we've got like 93 coverage i think we checked

recently we have almost 500 assert statements i mean yeah which which gives us a lot of confidence

to like continue to you know shift stuff around and build new features in the back end so took a

lot of time but it's saved many times more so that's that's one half of the story the other

half actually is we we spent a considerable amount of time like getting using ansible like writing

writing our own playbooks so that we can spin stuff up if we ever need to which actually has

happened multiple times we're like you know 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

redis server and then we decided like all right you know what 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 a 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 it takes you know five minutes

for us to deploy as many of these servers as we want

because of the time investment into Ansible up front,

which was maybe two or three days spread out a couple weeks.

Were you always on EC2?

I believe I read somewhere you were Heroku at one point,

or did you always go EC2?

No, no, no. We've always been EC2.

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? I think he's looking at me to confirm. Yes, we both have experience with EC2.

Andrew is more, Andrew's actually more comfortable with AWS because of his work

when he was in banking. I used to work at a company where you could like just go to an

internal website and provision a new Linux server. So for me, and 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 don't know i guess maybe we just find that it's easier yeah it's it's very we get

a machine we don't get someone's platform we don't get uh like the specialty hosting we get a machine

i can ssh into it i can do what i want that's to me that's simpler so yeah that's why we stuck

with ec2 but but let me say that uh and and i think this happens to us from time to time when

newer younger 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

pass 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 got to go through and i it's like a cliff of complexity yes like wow all of that so i want

to dig into your testing so you're testing the django your django application mainly 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 tester 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 yeah how do we

test uh we don't unfortunately 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 they're 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. We're, we spend so much time learning new ways to do things and mistakes that we were making

that we would have to rewrite our tests so frequently, more frequently than I think we'd

catch anything breaking because things haven't really, things haven't really been breaking too

much well fingers crossed but actually wait till you get off the show yeah exactly though i will

say the one thing that's actually useful here is that both swift and kotlin are type languages

and coming both of us have written 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

i did not yes appreciate what you get from that kind of strict typing and explicit typing

with with these languages and man i really like it yeah it's not a necessity for me going for i'm

still very happy with python i still enjoy writing that uh more but it's it has not been

an impediment for writing Kotlin.

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

But, yeah, it's been a very nice feature.

Not in my way at all, surprisingly.

It's like if it runs, there's a reasonable chance it runs right.

Yeah, surprisingly, actually.

Who would have thought?

Well, that's one of the open questions, I guess, in the Django community is whether to mandate or support typing.

And so far, they haven't weighed in, because there is obviously the tradeoff 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 sort of typing with Python because, yeah, it saves you time in the long run.

can i just say that i'm very pro type hints for django as well and i i follow the issue and i'm

like oh my god i really hope they 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 okay yeah everything we've written i think yeah

like all of our utility methods and stuff we we we type hint and do you using um like a type checker

with that as well like you're doing we're just using a built-in pycharm the problem is i installed

mypy and then it complained that all of the django stuff isn't typed so it's yeah yeah i know that if

you read the mypy docs in some depth it talks about how to progressively type your project but

it's like it's really hard to get anything going at all it's like i'm here for a day and i'm still

getting a thousand errors and i maybe i'm not clever enough to work out all the config options

but surely there should be a mypy progressive command that just sort of says look let's start

off with this one can you fix this one okay you fix that one can you fix this one now but that

doesn't exist um so we've mentioned performance but i'm curious as you've gone from prototype to

production have there been some notable big performance issues that cropped up and um and

how did you deal with them 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 one of the one of the testing speed ups we actually

it was an issue that we ran into at first where we had we were still sending our images because

you can upload images for your places and we have some sample images and we we mock the the upload

because we have a lot of custom stuff in that they were still getting sent to S3 through tests.

And I think S3 right now is littered with a bunch of test images.

Yeah, test underscore one, test underscore two.

Yeah.

A million of those.

So finding the right testing configurations, overriding your storage's config,

Which was, with the new 4.2 update, for a while it was tough to get the storage pointed towards storing locally.

Yeah. 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.

4.2.4.

Oh, 4.2.4 I guess maybe had to fix for it.

There's a small line in the patch notes about something.

I think it's like prioritizing how it gets storage.

It gets the proper storage.

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

It works now.

But we talked about earlier performance for testing.

We tried parallelizing it, which worked really well

until we needed to load in all that OSM coastline data.

Oh, actually, you know what's a really good performance thing?

I'll start it, but Andrew will finish it.

For our Explore page, when you first click it open

and you get all of the people's pins,

we have a monster SQL query for that.

We don't have any.

There's no machine learning just yet.

We had considered putting it in, but again,

perks of a two-person team, 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, yeah, that was, so we have, we, we have this ranking of all of our places

ranking with noise and it looked at all 10 000 of our pins and it did a lot of it did a lot of

operations a lot of counts a lot of over windows and partitions this is all orm by the way which

has been very and very nice and we managed to cut it down to what like 150 200 milliseconds

yeah roughly something like that just by excluding ones that we knew we wouldn't we wouldn't use so

the simplest solution cut out a ton of our actual query time where we just went in and

we're not going to want to present you know in the explorer things without images right it's

going to be a boring thing to look at and they're not going to get to it anyway no one's going to

scroll to four thousand and this is like a crazy six-way seven-way join 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 i like that i mean what's what's nice is that you've

got multi-second query bit of brain work comes down to you know quick enough yeah 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 carlton was it um matthias's django image field that we just

highlighted in the newsletter 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 it's just a little field that lets you um pick a upload an

image but and pick a point of interest a 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 the that's that's the bridge of my

nose there so well that's the point of my nose um and there are various options and but i wanted

But for various reasons, I wanted to use that one because it's less code.

That's cool, actually.

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

Yeah, we can look into that.

Just to talk a little –

You don't subscribe to the Django News newsletter because it was featured in there.

You know, I read every single one of those.

I have this one.

Me too sometimes.

Yeah, yeah.

I don't know what it is.

Maybe I prefer the podcast over reading.

I don't know what it is.

every time I see a podcast episode, I'm like, oh boy, here we go. That's how I stay up to date with

all the stuff in Django. For real though, people are surprised, like, how do you know all this

stuff about Django? And I'm like, there's an amazing podcast, you know, and it really does

help. I just spend too much time on Twitter. Yeah. Yeah. Okay. Well, I feel a little bit better

because sometimes I feel like I'm repeating myself because, you know, if it's like in the

newsletter, we mentioned on the podcast, maybe I write something about it, but I know that

not everyone is following every single thing that i do so um i need to that's good to hear

i will say uh just one comment about the the images 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 brilliant and so you will actually crop the image on the client before

uploading or yeah yeah 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 we know

what dimensions we're going to present to the user and yeah right so you no point having outside of

that yeah that's that's been the nice part about developing for mobile 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 and the 21-inch monitor at the same time.

Yeah.

And the angry user who uploaded that panoramic picture.

Yeah.

Why can't this be full-quality 100 meg?

Yeah.

Well, we're coming up a little on time.

Can you tell us what's next for PinPlanet?

You have, obviously, an Android app coming.

Are there any new things you're excited about working on?

related to it so i think the android app is is the biggest one we have tons and tons of people

that are asking about asking about it on android and uh 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, like a

short snippet out on YouTube and

we posted it on our socials and stuff

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.

I got four kids, I can't afford them.

I've seen

that in the simulator, when you show that to me.

It looks really cool.

Oh, we're on iPad too.

Oh yeah, Pin Planet does actually also work on iPad.

Oh.

Is that a recent thing or is that

that also supporting that was back that was back in october 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 so well there's i mean there's there's so many different

sizes of ipads these days but i guess on your end it wasn't like three times as much work to

support three different sizes with like the mini the air and the pro surprisingly not no 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 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 so android i'm worried about though some

devices won't even honor 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 there must there must be a hierarchy of you know the top two or

three android support devices have or i think have the lion's share or maybe not i don't actually

to know yeah well from whatever publicly available data we've got yeah and that's what we're targeting

right yeah yeah if it's that's the thing if it's it doesn't sound it's a big enough issue someone

will let you know yeah yeah it doesn't sound as if it's changed too much from my day it was like

very much like you know on the ios devices that was not too hard to customize them and then there

was a sea of different android options and you had to just pick the ones you had the sort of

capacity to support basically yeah yeah 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 actually i guess not random they're probably hugely uh popular devices in countries

like india or china or bangladesh and it's like all right these these are a little bit hard to

of support because they're they're a lot less expensive but they're way less powerful so yeah

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 that's a tricky portion to balance in my

opinion but that's also a cool engineering challenge and can i make this can i make the

app efficient so they all run on a lower end device i think yeah 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 if you

had a magic wand what would you fix i'll let you both have an answer if you want uh okay i have i

have two answers the first one would be i'd love to have typing and django that would be one and

then second i feel like this one maybe is a little bit less of a selfish 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 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

like old server rendered html templates when actually you can build very robust stable apis

with with django and also websocket support right so that would that would be mine i think more for

the benefit of the community okay interesting good andrew if you go the easiest one is to just

say throttling uh i i ran into some issues with like the granularity of throttling uh and you

know we wanted to restrict more of our rights versus our reads um and kind of ran into some

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 pin planet with some exceptions for our analytics dashboard but and i understand that it's

trying to be sequel back-end 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 sequel person i have a lot of experience with it and i can appreciate not wanting to require that

kind of experience for you know the new developer but sometimes it feels like

there's there's got to be some middle ground where you can more closely

reflect the sequel 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

and SQL. And you come back to Django and you're like, all right, what, what are these keywords

mean? What's actually happening? Uh, when does it allow me to not get the ID in this instance

versus requiring me to include the ID? Yeah. Yeah. Yeah. No, I get it. Well, I think we're,

we're, we're going to have, uh, Simon Charette on in the future who, who, uh, is that right,

Carlton I believe he agreed yeah yeah he said yes he's uh he's very very in the weeds on the

Django ORM um so we can we can pose that to him I'm sure he has a take oh no we could say Andrew

wanted to know right go on well you were good you were gonna okay is there anything we didn't

we didn't bring up um in our discussion um so obviously people can go on the app store

and maybe the Android store will put a link

by the time it comes out for PinPlanet.

Are there other ways people should stay in touch?

I don't think anything else really comes to mind.

If you use the app, leave us a rating in the app store.

That does actually help out significantly.

Yeah, I find that.

And then other than that,

I don't think there's anything else.

I mean, it's been a really fun journey.

I just want to emphasize again

that Django is just a phenomenal backend 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 building an

app it's nice when you don't have to worry about one portion of it you know that okay this just

works and and that's that's awesome good well we agree obviously but yeah i think it's also

yeah for the two of you for the two of you i mean it's it's quite a complex mature feeling app and

And so the fact that, you know, you can build it in a relatively short period of time, you should feel proud of that.

And it also speaks to the power of Django.

Yeah. Thank you.

Thank you very much.

Harood, Andrew, thank you for coming on.

I've really enjoyed the chat.

It's been absolutely super.

Thanks for joining us, folks, with DjangoChat.com.

And we'll see you next time.

Bye-bye.