494 lines
17 KiB
HTML
494 lines
17 KiB
HTML
<?xml version="1.0" encoding="utf-8"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
|
||
<head>
|
||
<title>The Models of Accounting</title>
|
||
<!-- 2013-11-25 Mon 22:56 -->
|
||
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
|
||
<meta name="generator" content="Org-mode"/>
|
||
<meta name="author" content="Joar Wandborg"/>
|
||
<style type="text/css">
|
||
<!--/*--><![CDATA[/*><!--*/
|
||
.title { text-align: center; }
|
||
.todo { font-family: monospace; color: red; }
|
||
.done { color: green; }
|
||
.tag { background-color: #eee; font-family: monospace;
|
||
padding: 2px; font-size: 80%; font-weight: normal; }
|
||
.timestamp { color: #bebebe; }
|
||
.timestamp-kwd { color: #5f9ea0; }
|
||
.right { margin-left: auto; margin-right: 0px; text-align: right; }
|
||
.left { margin-left: 0px; margin-right: auto; text-align: left; }
|
||
.center { margin-left: auto; margin-right: auto; text-align: center; }
|
||
.underline { text-decoration: underline; }
|
||
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
|
||
p.verse { margin-left: 3%; }
|
||
pre {
|
||
border: 1px solid #ccc;
|
||
box-shadow: 3px 3px 3px #eee;
|
||
padding: 8pt;
|
||
font-family: monospace;
|
||
overflow: auto;
|
||
margin: 1.2em;
|
||
}
|
||
pre.src {
|
||
position: relative;
|
||
overflow: visible;
|
||
padding-top: 1.2em;
|
||
}
|
||
pre.src:before {
|
||
display: none;
|
||
position: absolute;
|
||
background-color: white;
|
||
top: -10px;
|
||
right: 10px;
|
||
padding: 3px;
|
||
border: 1px solid black;
|
||
}
|
||
pre.src:hover:before { display: inline;}
|
||
pre.src-sh:before { content: 'sh'; }
|
||
pre.src-bash:before { content: 'sh'; }
|
||
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
|
||
pre.src-R:before { content: 'R'; }
|
||
pre.src-perl:before { content: 'Perl'; }
|
||
pre.src-java:before { content: 'Java'; }
|
||
pre.src-sql:before { content: 'SQL'; }
|
||
|
||
table { border-collapse:collapse; }
|
||
td, th { vertical-align:top; }
|
||
th.right { text-align: center; }
|
||
th.left { text-align: center; }
|
||
th.center { text-align: center; }
|
||
td.right { text-align: right; }
|
||
td.left { text-align: left; }
|
||
td.center { text-align: center; }
|
||
dt { font-weight: bold; }
|
||
.footpara:nth-child(2) { display: inline; }
|
||
.footpara { display: block; }
|
||
.footdef { margin-bottom: 1em; }
|
||
.figure { padding: 1em; }
|
||
.figure p { text-align: center; }
|
||
.inlinetask {
|
||
padding: 10px;
|
||
border: 2px solid gray;
|
||
margin: 10px;
|
||
background: #ffffcc;
|
||
}
|
||
#org-div-home-and-up
|
||
{ text-align: right; font-size: 70%; white-space: nowrap; }
|
||
textarea { overflow-x: auto; }
|
||
.linenr { font-size: smaller }
|
||
.code-highlighted { background-color: #ffff00; }
|
||
.org-info-js_info-navigation { border-style: none; }
|
||
#org-info-js_console-label
|
||
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
|
||
.org-info-js_search-highlight
|
||
{ background-color: #ffff00; color: #000000; font-weight: bold; }
|
||
/*]]>*/-->
|
||
</style>
|
||
<script type="text/javascript">
|
||
/*
|
||
@licstart The following is the entire license notice for the
|
||
JavaScript code in this tag.
|
||
|
||
Copyright (C) 2012 Free Software Foundation, Inc.
|
||
|
||
The JavaScript code in this tag is free software: you can
|
||
redistribute it and/or modify it under the terms of the GNU
|
||
General Public License (GNU GPL) as published by the Free Software
|
||
Foundation, either version 3 of the License, or (at your option)
|
||
any later version. The code is distributed WITHOUT ANY WARRANTY;
|
||
without even the implied warranty of MERCHANTABILITY or FITNESS
|
||
FOR A PARTICULAR PURPOSE. See the GNU GPL for more details.
|
||
|
||
As additional permission under GNU GPL version 3 section 7, you
|
||
may distribute non-source (e.g., minimized or compacted) forms of
|
||
that code without the copy of the GNU GPL normally required by
|
||
section 4, provided you include this license notice and a URL
|
||
through which recipients can access the Corresponding Source.
|
||
|
||
|
||
@licend The above is the entire license notice
|
||
for the JavaScript code in this tag.
|
||
*/
|
||
<!--/*--><![CDATA[/*><!--*/
|
||
function CodeHighlightOn(elem, id)
|
||
{
|
||
var target = document.getElementById(id);
|
||
if(null != target) {
|
||
elem.cacheClassElem = elem.className;
|
||
elem.cacheClassTarget = target.className;
|
||
target.className = "code-highlighted";
|
||
elem.className = "code-highlighted";
|
||
}
|
||
}
|
||
function CodeHighlightOff(elem, id)
|
||
{
|
||
var target = document.getElementById(id);
|
||
if(elem.cacheClassElem)
|
||
elem.className = elem.cacheClassElem;
|
||
if(elem.cacheClassTarget)
|
||
target.className = elem.cacheClassTarget;
|
||
}
|
||
/*]]>*///-->
|
||
</script>
|
||
</head>
|
||
<body>
|
||
<div id="content">
|
||
<h1 class="title">The Models of Accounting</h1>
|
||
<div id="table-of-contents">
|
||
<h2>Table of Contents</h2>
|
||
<div id="text-table-of-contents">
|
||
<ul>
|
||
<li><a href="#sec-1">1. Models</a>
|
||
<ul>
|
||
<li><a href="#sec-1-1">1.1. Account</a></li>
|
||
<li><a href="#sec-1-2">1.2. Entry</a></li>
|
||
<li><a href="#sec-1-3">1.3. Change</a></li>
|
||
<li><a href="#sec-1-4">1.4. Reports</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a href="#sec-2">2. The Unix philosophy</a>
|
||
<ul>
|
||
<li><a href="#sec-2-1">2.1. Rule of Modularity</a></li>
|
||
<li><a href="#sec-2-2">2.2. Rule of Clarity</a></li>
|
||
<li><a href="#sec-2-3">2.3. Rule of Composition</a></li>
|
||
<li><a href="#sec-2-4">2.4. Rule of Separation</a></li>
|
||
<li><a href="#sec-2-5">2.5. Rule of Simplicity</a></li>
|
||
<li><a href="#sec-2-6">2.6. Rule of Parsimony</a></li>
|
||
<li><a href="#sec-2-7">2.7. Rule of Transparency</a></li>
|
||
<li><a href="#sec-2-8">2.8. Rule of Robustness</a></li>
|
||
<li><a href="#sec-2-9">2.9. Rule of Representation</a></li>
|
||
<li><a href="#sec-2-10">2.10. Rule of Least Surprise</a></li>
|
||
<li><a href="#sec-2-11">2.11. Rule of Silence</a></li>
|
||
<li><a href="#sec-2-12">2.12. Rule of Repair</a></li>
|
||
<li><a href="#sec-2-13">2.13. Rule of Economy</a></li>
|
||
<li><a href="#sec-2-14">2.14. Rule of Generation</a></li>
|
||
<li><a href="#sec-2-15">2.15. Rule of Optimization</a></li>
|
||
<li><a href="#sec-2-16">2.16. Rule of Diversity</a></li>
|
||
<li><a href="#sec-2-17">2.17. Rule of Extensibility</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
<div id="outline-container-sec-1" class="outline-2">
|
||
<h2 id="sec-1"><span class="section-number-2">1</span> Models</h2>
|
||
<div class="outline-text-2" id="text-1">
|
||
<p>
|
||
My idea is to write this system in Python, using SQLAlchemy for
|
||
persistent storage.
|
||
</p>
|
||
|
||
<p>
|
||
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.
|
||
</p>
|
||
|
||
<p>
|
||
Each of the subsections present the attributes of the model, in SQL
|
||
these would be "fields".
|
||
</p>
|
||
|
||
<p>
|
||
My choice of SQLAlchemy and SQL is because of familiarity [from
|
||
mediagoblin, talkatv, [proprietary] projects] and that transactions,
|
||
accounts both have strong relations inbetween.
|
||
</p>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-1-1" class="outline-3">
|
||
<h3 id="sec-1-1"><span class="section-number-3">1.1</span> Account</h3>
|
||
<div class="outline-text-3" id="text-1-1">
|
||
<ul class="org-ul">
|
||
<li>Unique ID
|
||
</li>
|
||
<li>Name
|
||
</li>
|
||
<li>Parent ID, for hierarchical account structures
|
||
</li>
|
||
</ul>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-1-2" class="outline-3">
|
||
<h3 id="sec-1-2"><span class="section-number-3">1.2</span> Entry</h3>
|
||
<div class="outline-text-3" id="text-1-2">
|
||
<ul class="org-ul">
|
||
<li>Unique ID
|
||
</li>
|
||
<li>Summary, descriptive summary of the Changes herein
|
||
</li>
|
||
<li>Timestamp
|
||
</li>
|
||
</ul>
|
||
|
||
<p>
|
||
Represents a series of transactions(Changes) between different
|
||
accounts. The sum of the transactions must be 0.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-1-3" class="outline-3">
|
||
<h3 id="sec-1-3"><span class="section-number-3">1.3</span> Change</h3>
|
||
<div class="outline-text-3" id="text-1-3">
|
||
<ul class="org-ul">
|
||
<li>Unique ID
|
||
</li>
|
||
<li>Entry ID
|
||
</li>
|
||
<li>Account ID
|
||
</li>
|
||
<li>Value, fixed-precision value between -Infinity..+Infinity
|
||
</li>
|
||
</ul>
|
||
|
||
<p>
|
||
This model represents a change in an Account's value.
|
||
</p>
|
||
|
||
<p>
|
||
TODO: multi-currency
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-1-4" class="outline-3">
|
||
<h3 id="sec-1-4"><span class="section-number-3">1.4</span> Reports</h3>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2" class="outline-2">
|
||
<h2 id="sec-2"><span class="section-number-2">2</span> The Unix philosophy</h2>
|
||
<div class="outline-text-2" id="text-2">
|
||
<p>
|
||
Included for reference from
|
||
<a href="http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules">http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond.E2.80.99s_17_Unix_Rules</a>
|
||
</p>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-1" class="outline-3">
|
||
<h3 id="sec-2-1"><span class="section-number-3">2.1</span> Rule of Modularity</h3>
|
||
<div class="outline-text-3" id="text-2-1">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-2" class="outline-3">
|
||
<h3 id="sec-2-2"><span class="section-number-3">2.2</span> Rule of Clarity</h3>
|
||
<div class="outline-text-3" id="text-2-2">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-3" class="outline-3">
|
||
<h3 id="sec-2-3"><span class="section-number-3">2.3</span> Rule of Composition</h3>
|
||
<div class="outline-text-3" id="text-2-3">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-4" class="outline-3">
|
||
<h3 id="sec-2-4"><span class="section-number-3">2.4</span> Rule of Separation</h3>
|
||
<div class="outline-text-3" id="text-2-4">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-5" class="outline-3">
|
||
<h3 id="sec-2-5"><span class="section-number-3">2.5</span> Rule of Simplicity</h3>
|
||
<div class="outline-text-3" id="text-2-5">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-6" class="outline-3">
|
||
<h3 id="sec-2-6"><span class="section-number-3">2.6</span> Rule of Parsimony</h3>
|
||
<div class="outline-text-3" id="text-2-6">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-7" class="outline-3">
|
||
<h3 id="sec-2-7"><span class="section-number-3">2.7</span> Rule of Transparency</h3>
|
||
<div class="outline-text-3" id="text-2-7">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-8" class="outline-3">
|
||
<h3 id="sec-2-8"><span class="section-number-3">2.8</span> Rule of Robustness</h3>
|
||
<div class="outline-text-3" id="text-2-8">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-9" class="outline-3">
|
||
<h3 id="sec-2-9"><span class="section-number-3">2.9</span> Rule of Representation</h3>
|
||
<div class="outline-text-3" id="text-2-9">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-10" class="outline-3">
|
||
<h3 id="sec-2-10"><span class="section-number-3">2.10</span> Rule of Least Surprise</h3>
|
||
<div class="outline-text-3" id="text-2-10">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-11" class="outline-3">
|
||
<h3 id="sec-2-11"><span class="section-number-3">2.11</span> Rule of Silence</h3>
|
||
<div class="outline-text-3" id="text-2-11">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-12" class="outline-3">
|
||
<h3 id="sec-2-12"><span class="section-number-3">2.12</span> Rule of Repair</h3>
|
||
<div class="outline-text-3" id="text-2-12">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-13" class="outline-3">
|
||
<h3 id="sec-2-13"><span class="section-number-3">2.13</span> Rule of Economy</h3>
|
||
<div class="outline-text-3" id="text-2-13">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-14" class="outline-3">
|
||
<h3 id="sec-2-14"><span class="section-number-3">2.14</span> Rule of Generation</h3>
|
||
<div class="outline-text-3" id="text-2-14">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-15" class="outline-3">
|
||
<h3 id="sec-2-15"><span class="section-number-3">2.15</span> Rule of Optimization</h3>
|
||
<div class="outline-text-3" id="text-2-15">
|
||
<p>
|
||
Developers should prototype software before polishing it. This rule
|
||
aims to prevent developers from spending too much time for marginal
|
||
gains.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-16" class="outline-3">
|
||
<h3 id="sec-2-16"><span class="section-number-3">2.16</span> Rule of Diversity</h3>
|
||
<div class="outline-text-3" id="text-2-16">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
|
||
<div id="outline-container-sec-2-17" class="outline-3">
|
||
<h3 id="sec-2-17"><span class="section-number-3">2.17</span> Rule of Extensibility</h3>
|
||
<div class="outline-text-3" id="text-2-17">
|
||
<p>
|
||
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.
|
||
</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div id="postamble" class="status">
|
||
<p class="author">Author: Joar Wandborg</p>
|
||
<p class="date">Created: 2013-11-25 Mon 22:56</p>
|
||
<p class="creator"><a href="http://www.gnu.org/software/emacs/">Emacs</a> 24.3.1 (<a href="http://orgmode.org">Org</a> mode 8.0.6)</p>
|
||
<p class="xhtml-validation"><a href="http://validator.w3.org/check?uri=referer">Validate XHTML 1.0</a></p>
|
||
</div>
|
||
</body>
|
||
</html>
|