nikolak · August 29, 2015 14:26 · Jul 30, 2015 · Jul 30, 2015 · Jul 30, 2015
diff --git a/m.md b/m.md
@@ -82,4 +82,6 @@
 * 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
+* 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](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/)
diff --git a/m.md b/m.md
@@ -1,9 +1,7 @@
 # General
 
 * Django 1.7 EOL ~1yr after product release (1.8 is LTS) - migration should be easy [docs](https://docs.djangoproject.com/en/1.8/releases/1.8/#features-deprecated-in-1-8)
-
 * 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](https://docs.djangoproject.com/en/1.8/topics/serialization/#serialization-formats-json)
 * 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](https://www.opencredo.com/2015/07/28/rest-api-tooling-review/)

diff --git a/m.md b/m.md
@@ -0,0 +1,87 @@
+# General
+
+* Django 1.7 EOL ~1yr after product release (1.8 is LTS) - migration should be easy [docs](https://docs.djangoproject.com/en/1.8/releases/1.8/#features-deprecated-in-1-8)
+
+* 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](https://docs.djangoproject.com/en/1.8/topics/serialization/#serialization-formats-json)
+* 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](https://www.opencredo.com/2015/07/28/rest-api-tooling-review/)
+
+# 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](https://www.jetbrains.com/pycharm/help/type-hinting-in-pycharm.html)
+
+## Django practices and tools
+
+* Using `HttpResponse` instead of `JsonResponse` [doc](https://docs.djangoproject.com/en/dev/ref/request-response/#jsonresponse-objects) - 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](https://docs.djangoproject.com/en/1.8/topics/logging/) 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
No results found