Technical Policy

Version 1.0 2009-06-05 James Gardner

Introduction

This document describes the approach taken by 3aims Ltd towards the technology we choose for the products we develop, the coding and style conventions we use and our support and maintainance procedure.

Choice of Platform

3aims Ltd and its partners are very technically-minded people so we prefer solutions where we have direct access to the source code which makes up products so that we can see how it works and fix it when we discover problems. We will therefore avoiding working with technologies such as Windows or .NET where possible to avoid being reliant on another company to help when problems were found.

3aims Ltd will only use open source software and our current choice of platform is as follows:

  • Debian Linux 5.0
  • Apache 2 with mod_wsgi
  • OpenVZ vitualization
  • Nginx proxy / load balancer
  • Postfix 2.5 SMTP server
  • Dovecot 1.1 IMAP server

3aims Ltd will maintain a list of tutorials at http://goodingredients.org to help other people in the community work with these components.

Choice of Language

New websites will be written in the Python language, the same language used by Google, NASA and many others.

For browser work or under circumstances on the server, the JavaScript langauge will be used.

Choice of Databases

3aims Ltd will investigate the appropriate choice of databases for the task in hand but often find PostgreSQL to be a good fit for many problems. Technologies such as CouchDB also offer interesting oppurtunities.

3aims Ltd will avoid the use of object relational mappers where at all possible and instead favour a task-oriented approach featuring direct manipulation of the database in whatever format is appropriate. In the case of PostgreSQL this means the use of the SQL langauge. It is therefore expected that developers working with 3aims Ltd will be able to learn simple SQL.

Application Architecture

3aims Ltd web applications will use the 3aims Ltd Application Architecture, described in detail on the developer page.

Coding Conventions

Python code should obey all the conventions described in PEP 8 with the following exceptions:

  • Import statements can appear at any point in the code so that modules are only imported if they are needed

    The advantage of this approach is that it speeds load performance.

  • Any time a line of code cannot be written in 79 characters it should be formatted so that every item is expanded to its own line, not just broken in half with the rest of the line on the next line. As an example, this code formatted according to PEP 8:

    raise PermissionError("You do not have permission to access the resource %s, "
        "please sign in as a different user." % (resource_name))
    

    would be written:

    raise PermissionError(
        "You do not have permission to access the resource %s, "
        "please sign in as a different user." % (
            resource_name,
        )
    )
    

    The advantage of this approach is that changes to one part of the statement can be clearly seen in diffs and it is easier to match closing brackets.

SQL Naming Conventions

3aims Ltd will follow the 3aims Ltd SQL Naming Conventions wherever possible. SQL naming conventions are arguably more important than Python code conventions since the SQL conventions will be inform upon the choice of Python variable names.

Support and Maintenance

3aims Ltd put a high emphasis on support and maintenance. Any time a new version of the 3aims Ltd Application Architecture is released we will upgrade existing code to meet the new architecture. This is a time-consuming process and requires cooperation from the project sponsor and business users as well as the technical team but it also forces re-evaluation of the existing code and helps keep the project from becoming out of date. For any project worth continuing this is an important factor.

3aims Ltd will not continue to support products where the business will not commit time or finances for ongoing support and maintenance.

3aims Ltd will not continue to support products where third party libraries have been introduced or where external developers have changed the code structure or architecture.

(view source)