The Server is based on Django framework, a high-level Python Web framework. The reasons that has led us base our development on this framework are:

• Fast development and clean design
• Comprehensive documentation
• Automatic admin interface
• Background with the framework

A more detailed discussion of the options can be found here.

Each piece of functionality is split into different applications. An app should be focused and follow the Unix philosophy of “do one thing and do it well”. In other words, an application encapsulates some particular feature. If this sounds new to you, maybe you're interested in this talk.

• When a piece of code is considered generic or can be used in different applications it should live on the main controller application.
• All images/code/files that are Confine related should live on the controller module.

Following the Python modules that you can expect to find inside each application:

• admin.py Admin interface support provided by django.contrib.admin.
• api.py REST API views based on Django REST Framework.
• models.py Models of the application (data layer)
• permissions.py Permission definitions (see Permissions Application).
• settings.py Settings of the application (see Django settings).
• urls.py: URLs configuration (see URL dispatcher).
• views.py Django views

• actions.py: Admin actions.
• filters.py: model admin list filter.

• fields.py Model and Form Fields.
• forms.py Django forms.
• widgets.py Forms widgets.

• renderers.py: REST API renderers (see DRF renderers).
• serializers.py REST API serializers (see DRF serializers guide).

• ifaces.py Sliver network interface definitions.
• notifications.py: pluggable notification system based on server-apps-notifications notification app.
• tasks.py: Celery tasks (Celery is an asynchronous task queue/job queue based on distributed message passing).

• utils.py Functions that do one repetitive and specific thing.
• helpers.py Functions that are part of other functions, in contrast with utils, helpers functions are highly coupled with their parent and do not have context other than that.
• validators.py Django validators.

• tests.py Tests (see Testing in Django).

Apart from the ovbious benefit for others because of being able to reuse our software, writing code with reusability in mind also helps to keep the code structure clean and modular. Keep this in mind:

• Any component can be relpaced in any moment (apps)
• Constant parameters can change over time (settings)
• Each single component should be able to be reused on other projects (apps)

These are ideal states, be pragmatic above all :)

Well known related design principles:

• Separation Of Concerns
• Loose Coupling
• Orthogonality

Advanced tutorial: How to write reusable apps

Some online resources that can be worth reading

1. http://agiliq.com/static/books/djangodesignpatterns/
2. http://lincolnloop.com/django-best-practices/
3. http://www.quora.com/What-are-some-Best-Practices-for-Django-Development
4. http://stackoverflow.com/questions/550632/favorite-django-tips-features
5. http://www.ramavadakattu.com/top-10-tips-to-a-new-django-developer
6. http://stevelosh.com/blog/2011/06/django-advice/

• Django 1.4 Cheat Sheet

1. https://python-guide.readthedocs.org/en/latest/
2. http://python.net/~goodger/projects/pycon/2007/idiomatic/
3. http://learnpython.pbwiki.com/PythonTricks
4. http://eikke.com/how-not-to-write-python-code/
5. http://eikke.com/python-gotcha/

We will follow these guidelines:

1. Django coding style
2. PEP 8 -- Style Guide for Python Code
3. Confine Coding guidelines

• Let's try to follow this branching model

In general try to write as less code as possible. And remember Don't repeat yourself, Keep it simple! and Repair broken windows!

Be careful choosing class, function and variable names: be descriptive and avoid abbreviations if they aren't clear (characters are almost free :)

Naming convention:

• class: SingularName
• action function: verb_name() (validate_user(), get_whatever(), make_something())
• boolean function: has_something() (has_permission(), has_blue_eyes())
• date attributes: attribute_on (deleted_on)
• boolean attributes: is_something, allow_something (is_active, allow_slices)
• properties: like if they where attributes

If your code needs to be commented maybe is because it is too complex, give it a second thought!

Readings that you might find interesting:

• Code Complete (2nd edition) by Steve McConnell
• The Pragmatic Programmer
• Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
• and more