Added stub on the models of accounting
This commit is contained in:
Joar Wandborg
parent
440d3fef79
commit
36fc93837d
2 changed files with 632 additions and 0 deletions
494
Words/accounting.html
Normal file
494
Words/accounting.html
Normal file
|
|
@ -0,0 +1,494 @@
|
||||||
|
<?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>
|
||||||
138
Words/accounting.org
Normal file
138
Words/accounting.org
Normal file
|
|
@ -0,0 +1,138 @@
|
||||||
|
#+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.
|
||||||
Loading…
Reference in a new issue