diff options
author | Darren Bane <darren.bane@emdalo.com> | 2020-06-01 21:21:10 +0100 |
---|---|---|
committer | Darren Bane <darren.bane@emdalo.com> | 2020-06-01 21:21:10 +0100 |
commit | f0467d992324a56ee5fdf8c94ee2608db0a61ac3 (patch) | |
tree | ac1223a4fe439b362809275b5af1034fb0770c36 /doc | |
parent | 98097b4c73f274f95bf1360a2b2f99b555917cd5 (diff) | |
download | lsp-f0467d992324a56ee5fdf8c94ee2608db0a61ac3.tar.gz |
Making changes
Diffstat (limited to 'doc')
-rw-r--r-- | doc/breaking_rules.md | 21 |
1 files changed, 15 insertions, 6 deletions
diff --git a/doc/breaking_rules.md b/doc/breaking_rules.md index a20bdac..7933efb 100644 --- a/doc/breaking_rules.md +++ b/doc/breaking_rules.md @@ -24,11 +24,6 @@ invalidated this. *TODO*: case study -*Colophon*: this document tries to depend only on GFM, -in the same spirit as the software. -The use of tools like -PP, PlantUML and Pandoc is postponed indefinitely. - # Literature Review There is a long history of recommending prototyping as a way to construct @@ -90,7 +85,9 @@ The following technology is recommended: * Emacs for the view layer * JSON-RPC for inter-process communication -Even though this is a prototype, attention should be paid to basic craftsmanship: +## Codinmg standards + +Even though this is a prototype, attention should be paid to basic craftsmanship. * Divide the system into packages, using at least the subset of CL that is supported by OpenLisp @@ -142,6 +139,14 @@ Then, the following code & documentation improvements should be made: ## Documentation Details +Depend only on GFM, +in the same spirit as the software. +The use of tools like +PP and Pandoc is postponed indefinitely. +PlantUML *should* be used where it can replace ad-hoc text. + +Documents should be stored under git in a "doc" subdirectory of the project. + I think it is a good idea to keep the separation between library and UI code. And JSON-RPC is perfectly adequate for that. @@ -172,6 +177,9 @@ The following can be added as sections to the README: And a proper software requirements spec should be written filling in any blanks that the man pages leave. The specification of input and output variables is best left at the level of tables and Basic English again. +For the UI *technology*, it's probably best to skip local GUIs altogether and go +straight to ParenScript, Backbone, etc. + ## Testing Unit (olunit) tests should be derived from the module interface specs. @@ -180,6 +188,7 @@ System tests should be derived from the requirements spec. It's ok for system tests to use the JSON-RPC interface. All tests should be automated, except possibly for the UI/view layer. +Q: These scripts could be generated from a literate test plan? Where there is scope to push some of the testing work "back" in the V model to contracts for the functions, this should be done instead. |