Django App skeleton

Based off of https://github.com/dereknutile/django-1.7-template, which is itself based off of https://github.com/twoscoops/django-twoscoops-project

Not fully working yet because we need some devops/infrastructure work to setup dependencies and connect to the services VM
> Interesting point. The situation we ended up in on OTM is that we backed ourselves into a corner by using postgres-specific plugins and then switching away from postgres was not an option. As long as we don't do that, we can delay this decision.
>
> It's worth noting that "run your tests with SQLite" is commonly listed as a django best practice for faster tests. I've seen this mentioned by numerous people in talks at conferences or on blogs. It's actually also recommend that you write your code so that as little as possible happens on save, so that your unit tests can avoid saving entirely and work solely with python objects in memory.

Yep. I've seen mentions of people saying they use SQLite to run test suites, but I've also seen people advocate using the same database backend across environments (development, test, production). I personally feel more comfortable with the latter.

If people want to use the SQLite backend to run tests locally before committing, that seems like a fair compromise. But I definitely want CI to be running tests against the same backend we plan to use in production.

> Going down different code paths in the ORM is not a huge concern, because django undoubtedly has unit tests for this. We should feel confident that our ORM knows how to write data to databases, else we should use a different ORM. Our task is to test the code we write on top of the ORM.

My comment is not a criticism of Django or Django ORM quality, it is more an observation of software in general. Django has unit tests, our software has unit tests, but bugs still exist. If we run the test suite with the SQLite backend and a test fails, but the same suite doesn't fail with a PostgreSQL backend, will we dig into the root cause? If the opposite happens, will we merge the code and feel confident deploying it?

I agree that our task is to test the code we write on top of the ORM, but if part of the test involves interacting with a database, or interacting with a different module in the ORM code, that interaction contributes to the outcome of the test no matter what.

> If it turns out that running our tests on a different db stack leads to silent bugs, it will be a lot easier to migrate to postgres than from it, with postgres being a superset of sqlite in all(?) cases.

Not sure I follow here. 

> I'm not sure, but I believe we've looked at running postgres on a ram disk and it didn't run much faster?

Details around this would be good to know. It probably won't be as fast at SQLite because most likely we'd be going over the network to talk to PostgreSQL.