Tips for Building High-Quality Django Apps at Scale • Hacker News Board

Re: Tips for Building High-Quality Django Apps at Scale

#121

Post by dangayle » Thu, May 18, 2017, 7:16 PM UTC

jwarren116 wrote: post #105

dangayle wrote: post #29

Earlier quoted context omitted.

Have you checkout out O'Reilly's Lightweight Django book? It basically goes through all of this, starting with a single file Django app.

+1 for Lightweight Django. I had the pleasure of working with one of the authors. The book is well laid out and covers some really great topics that aren't always covered well elsewhere in the context of Django (i.e. Websocket services with Django). It's a great companion for Two Scoops of Django.

In my opinion that book should be the starting point. The official tutorials have you way deep in the weeds with database migrations and stuff before you even have a basic understanding of where you're at and why. Worst "hello world" ever.

Re: Tips for Building High-Quality Django Apps at Scale

#122

Post by tinix » Fri, May 19, 2017, 12:10 AM UTC

allover wrote: post #113

tinix wrote: post #94

Earlier quoted context omitted.

1. Change model code to add the new field, test, and commit it to version control. Then it's merged to staging, where it's tested in a production-like environment with a recent production data snapshot. After that's approved, it goes to master/production servers. 2. git pull then restart some wsgi/worker processes 3. git checkout to desired revision and restart some wsgi/worker processes It's perfectly fine to have m…

You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.

There is no schema change, that's the point. You just don't get it... but that's okay.

Re: Tips for Building High-Quality Django Apps at Scale

#123

Post by nezo » Fri, May 19, 2017, 6:37 AM UTC

About ContentType : "If you ever move models between apps or rename your apps, you’re going to have to do some manual patching on this table"

Thanks for this, just had a kind of struggle recently

Re: Tips for Building High-Quality Django Apps at Scale

#124

Post by marcosdumay » Fri, May 19, 2017, 12:38 PM UTC

randomsearch wrote: post #60

marcosdumay wrote: post #49

Earlier quoted context omitted.

> why not make the reuse optional? Well, it is optional. You can just not divide you stuff and place everything inside the main app. But notice the article recreates the same layer of reuse inside the main app, and got some extra problems because of it (renaming the tables is probably caused by this). Django may need an extra paragraph at the tutorial, telling how it is ok to place everything on the main app when eve…

> Well, it is optional What I mean is, you still have to have a "main" app. Why? I don't want to reuse it. So I don't want an "app". I just want to build my website. Stop making me put things in an unnecessarily complicated directory hierarchy. If it were Java, I wouldn't think twice about it, but it doesn't seem Pythonic. > reverse Dunning-Kruger Good question! Probably... illusory inferiority AKA imposter syndrome.…

> you still have to have a "main" app

Well, it has to be organized some way. It happens to have the organization that gives you more flexibility, instead of forcing something that only fits very small sites onto you. That means you'll have an extra directory on your tree.

Anyway, nobody uses only the main app. The article creates a big amount of problems by trying to only write on it, but I bet that even them use the Django's builtin apps.

> AKA imposter syndrome

Oh. Dunning-Kruger study detected that one too. It's within the effect: people tend to self evaluate into a small band near (but often under) the top, whatever their real evaluation is.

Re: Tips for Building High-Quality Django Apps at Scale

#125

Post by allover » Fri, May 19, 2017, 9:20 PM UTC

tinix wrote: post #122

allover wrote: post #113

Earlier quoted context omitted.

You missed the point of all those questions (e.g. in 2 you don't mention how the schema change gets applied to the prod database). Unfortunately I'm frankly out of patience explaining any further, so we'll have to leave it there.

There is no schema change, that's the point. You just don't get it... but that's okay.

Okay you didn't read the question then.

> [...] you changed the DB schema in your 'dev' environment to add a column [...]

The 'point' is we are adding a column, and we want a sane workflow that works in a team from dev through to production.