139 lines
6.3 KiB
Org Mode
139 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.
|