From f0467d992324a56ee5fdf8c94ee2608db0a61ac3 Mon Sep 17 00:00:00 2001 From: Darren Bane Date: Mon, 1 Jun 2020 21:21:10 +0100 Subject: Making changes --- doc/breaking_rules.md | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) (limited to 'doc') 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. -- cgit 1.4.1-2-gfad0 /akkartik/mu/blame/?h=hlt&id=a42f4613f785163223c8416bd7fa720bc932ed88'>root/linux/201register-names.subx
blob: 3c18a803fbee0a74d4ff72ccfcae85aa6f455850 (plain) (tree)
1
2
3
4
5
6
7
8