Changeset - 36fc93837d7d
[Not reviewed]
0 0 2
Joar Wandborg - 7 years ago 2013-11-25 21:57:26
joar@wandborg.se
Added stub on the models of accounting
2 files changed with 632 insertions and 0 deletions:
0 comments (0 inline, 0 general)
Words/accounting.html
Show inline comments
 
new file 100644
 
<?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>
Words/accounting.org
Show inline comments
 
new file 100644
 
#+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.
0 comments (0 inline, 0 general)