m.md

General

• Django 1.7 EOL ~1yr after product release (1.8 is LTS) - migration should be easy docs
• Testing - planned? Core features should be covered before release.
• Moving controllers into their own apps?
• Performance overhead by generating new dicts all the time? Maybe stroing json or using serialization? docs
• Approach the communication between frontend and backend as a RESTful API that it is. Create API specs and docs. Suggestion: http://swagger.io/ some tool overview

Code

Style issues

• Shadowing builtins (file, dict, etc)
• Shadowing from outer scope
• Using depreciated tools - md5
• A lot of @staticmethod - necessary for loading/using modules?
• redirect (e.g. in build_template) should not redirect to a page that can redirect back to it without checking whether there's an inf. recursion happening (happened to me) -- could be harder to debug in production.
• Often dictionary creation could be rewritten with dictionary literal.
• PEP8 standard (small issues): Double quoted string for docstrings, line alignment, line length etc
• Too broad exception clauses - PITA to debug
• No docs
• No typehints pycharm docs

Django practices and tools

• Using HttpResponse instead of JsonResponse doc - why?
• Not using reverse for urls where possible
• (Security) hardcoded passwords in repository (solution: https://devcenter.heroku.com/articles/config-vars) (also insecure passwords)
• Mixing class based and function based views - not consistent

Settings

• Not separated into local, dev, production
• Things like LOGIN_URL should be defined in settings

Development

• Too permissive gitignore (potential config/settings in repo) - local proposal
• No local development setup - will make deployment and development easier
• No separated requirements.txt - same as above
• No makefiles - makes running local commands easier
• Unused requirements? (mysql comes to mind)
• Old(?) quickbase related things? For migrations?
• Test data - creating a new instance without any data is harder than it should be. https://docs.djangoproject.com/en/1.8/howto/initial-data/ Useful for demo purposes too
• Benefits of keeping old migrations during development? AFAIK there aren't any.

General data gathering/displaying structure?

+-----------+    GET     +----------------+
|   Data    | <--------> |   web/model/*  |
+-----------+            +-------+--------+
                                 |         
                                 |         
+--------+   +---------+   +-----v------+  
|  JSON  <---> Django  <---> Database   |  
+---^----+   +---------+   +------------+  
    |                                      
    |                                      
    |                                      
+---v------------------+                   
|   Angular/Frontend   |                   
+----------------------+                   

Development suggestions

Short term (before release) suggestions

• Write tests covering logging in, urls, core models.
• Mandatory style tests before committing changes. To catch at least syntax errors and similar things.
• Mandatory docs w/ type hinting for new functions/methods.
• Additional logging docs right now you'll get HTTP 500 errors in some cases and won't see any additional info. Also while on topic of logging, drop the print statements.
• Django Forms for basic things like registration.

Long term

• Go back and write docs for all functions
• Improve logging in non-critical functions
• Handle errors between frontend and backend
• Multiple apps maybe?
• Tests for everything
• Move to django forms completely
• Figure out angular testing
• I'd move "model" to a separate directory or an app, to separate the API part and the data gathering part.
• Other minor suggestions
• Tools for project management that would be used by management for having a clear overview of features, bugs and expected ETAs. Pros for developers: Easier communication, clearer work schedule, clearer deadlines, integration with github depending on the tool possible. Integrate with travis-ci, coveralls.
• Move to git-flow development and committ structure instead of staging>master. http://nvie.com/posts/a-successful-git-branching-model/ and a tutorial