Demovibes source cleanup

demovibes.md

I looked at the existing codebase and taking into account my experiences with previous Django projects/deployments I would suggest to do the following:

• Change directory structure to something more modular and structured
• Lose all old south migrations and create inital ones for 1.8
• Check all models for changes with 1.8, because there will be
• Get a mysql slave up on my vps to test the new setup
• Use nginx as reverse proxy for gunicorn and to serve static content (and node.js if it's used)
• Use supervisord to keep an eye on processes (gunicorn, node.js, etc.)
• Integrate existing config in a more generic way of handling configs (dev/staging/live)
• Start rewriting views (from what I have seen, this should be quite doable with existing packages like django-class-based-auth-views and the work already done)
• All jinja2 => django templates (yawn, this is going to be the boring part)
• All ajax and client side JS that needs refactoring
• Make it deployable via Travis-CI

Like I said, would be cool to be able to do this, but the changes are quite radical, so I forked the repo and will start working on that.

Cheers, Richard

👍

Also, please take note of what the previous developer left for us:

Quote: "the obvious things would be to clean up the codebase. Make it Django 1.8 compatible, get everything over on one render engine instead of two, use django's generic class based views instead of the function based ones and my own class based view system I made before django had it's own, and so on.

also standardize some things like ajax and client side JS, which have different implementations here and there as I were learning better ways to do things over time.

and if that sounds like a truckload of very boring drudgework, you'd be absolutely correct."

Thanks! :)

Some 2 cents:

• a south migration step between current layout and 1.8 would be much desired as a precondition for the currently running setup.
• we already use nginx for static content serving ect.
• why change to gunicorn? we've been using uwsgi for ages and consider it rock stable.
  • http://blog.kgriffs.com/2012/12/18/uwsgi-vs-gunicorn-vs-node-benchmarks.html

Sidenote: A fix for current openid mess would be top1-prio & highly desired. I'm unfortunately not skilled enough to fix it.

Well, gunicorn is just what I've seen people use and I'm quite happy with it, but I'm not saying we have to use it ;)

Okay, I'll dive into that. I do have some experience with django-allauth which also includes openID

http://django-allauth.readthedocs.org/en/latest/providers.html

Just a small FYI: There's also some local, scenemusic-unique changes that might conflict with the new code, so it might not be a clean deploy

For the general version it should be ok, any specific nectarine changes will be resolved manually (hopefully) by me.

If not, it might be necessary to back out from the nectarine-specific changes - and maintain a clean codebase.

I'm not quite sure django-allauth supports the
https://support.google.com/accounts/answer/6206245?p=openid&rd=1 OpenidConnect from google.
If not - maybe use:
https://github.com/omab/python-social-auth
http://psa.matiasaguirre.net/docs/backends/google.html

Can we isolate these nectarine specific changes?

Oh yeah, from the changelog of 1.6:

Pillow is now the preferred image manipulation library to use with Django. PIL is pending deprecation (support to be removed in Django 1.8). To upgrade, you should first uninstall PIL, then install Pillow.