Files @ f15dffb821c2
Branch filter:

Location: NPO-Accounting/npo-accounting-ikiwiki/Words/accounting.org

http://wandborg.se/ Joar@web
#+TITLE: The Models of Accounting
#+AUTHOR: Joar Wandborg
* Models
  My idea is to write this system in Python, using SQLAlchemy for
  persistent storage.

  The following subsections are the models that I think apply to a
  bare-bone accounting API. The word "Model" is borrowed from
  SQLAlchemy where a Model is an abstraction of an SQL database table.
  
  Each of the subsections present the attributes of the model, in SQL
  these would be "fields".

  My choice of SQLAlchemy and SQL is because of familiarity [from
  mediagoblin, talkatv, [proprietary] projects] and that transactions,
  accounts both have strong relations inbetween.

** Account
   - Unique ID
   - Name
   - Parent ID, for hierarchical account structures
** Entry
   - Unique ID
   - Summary, descriptive summary of the Changes herein
   - Timestamp

   Represents a series of transactions(Changes) between different
   accounts. The sum of the transactions must be 0.
** Change
   - Unique ID
   - Entry ID
   - Account ID
   - Value, fixed-precision value between -Infinity..+Infinity

   This model represents a change in an Account's value.
   
   TODO: multi-currency
** Reports
* The Unix philosophy
  Included for reference from
  http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules

** Rule of Modularity
   Developers should build a program out of simple parts connected by
   well defined interfaces, so problems are local, and parts of the
   program can be replaced in future versions to support new
   features. This rule aims to save time on debugging code that is
   complex, long, and unreadable.
** Rule of Clarity
   Developers should write programs as if the most important
   communication is to the developer, including him- or herself, who
   will read and maintain the program rather than the computer. This
   rule aims to make code readable and comprehensible for whomever
   works on the code in future.
** Rule of Composition
   Developers should write programs that can communicate easily with
   other programs. This rule aims to allow developers to break down
   projects into small, simple programs rather than overly complex
   monolithic programs.
** Rule of Separation
   Developers should separate the mechanisms of the programs from the
   policies of the programs; one method is to divide a program into a
   front-end interface and back-end engine that interface communicates
   with. This rule aims to let policies be changed without
   destabilizing mechanisms and consequently reducing the number of
   bugs.
** Rule of Simplicity
   Developers should design for simplicity by looking for ways to
   break up program systems into small, straightforward cooperating
   pieces. This rule aims to discourage developers’ affection for
   writing “intricate and beautiful complexities” that are in reality
   bug prone programs.
** Rule of Parsimony
   Developers should avoid writing big programs. This rule aims to
   prevent overinvestment of development time in failed or suboptimal
   approaches caused by the owners of the program’s reluctance to
   throw away visibly large pieces of work. Smaller programs are not
   only easier to optimize and maintain; they are easier to delete
   when deprecated.
** Rule of Transparency
   Developers should design for visibility and discoverability by
   writing in a way that their thought process can lucidly be seen by
   future developers working on the project and using input and output
   formats that make it easy to identify valid input and correct
   output. This rule aims to reduce debugging time and extend the
   lifespan of programs.
** Rule of Robustness
   Developers should design robust programs by designing for
   transparency and discoverability, because code that is easy to
   understand is easier to stress test for unexpected conditions that
   may not be foreseeable in complex programs. This rule aims to help
   developers build robust, reliable products.
** Rule of Representation
   Developers should choose to make data more complicated rather than
   the procedural logic of the program when faced with the choice,
   because it is easier for humans to understand complex data compared
   with complex logic. This rule aims to make programs more readable
   for any developer working on the project, which allows the program
   to be maintained.
** Rule of Least Surprise
   Developers should design programs that build on top of the
   potential users' expected knowledge; for example, ‘+’ should always
   mean addition in a calculator program. This rule aims to encourage
   developers to build intuitive products that are easy to use.
** Rule of Silence
   Developers should design programs so that they do not print
   unnecessary output. This rule aims to allows other programs and
   developers to pick out the information they need from a program's
   output without having to parse verbosity.
** Rule of Repair
   Developers should design programs that fail in a manner that is
   easy to localize and diagnose or in other words “fail
   noisily”. This rule aims to prevent incorrect output from a program
   from becoming an input and corrupting the output of other code
   undetected.
** Rule of Economy
   Developers should value developer time over machine time, because
   machine cycles as of the year 2013 are relatively inexpensive
   compared to prices in the 1970s. This rule aims to reduce
   development costs of projects.
** Rule of Generation
   Developers should avoid writing code by hand and instead write
   abstract high-level programs that generate code. This rule aims to
   reduce humans errors and save time.
** Rule of Optimization
   Developers should prototype software before polishing it. This rule
   aims to prevent developers from spending too much time for marginal
   gains.
** Rule of Diversity
   Developers should design their programs to be flexible and
   open. This rule aims to make programs flexible, allowing them to be
   used in other ways than their developers intended.
** Rule of Extensibility
   Developers should design for the future by making their protocols
   extensible, allowing for easy plugins without modification to the
   program's architecture by other developers, noting the version of
   the program, and more. This rule aims to extend the lifespan and
   enhance the utility of the code the developer writes.