138 lines
6.3 KiB
Org Mode
138 lines
6.3 KiB
Org Mode
#+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.
|