marko 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/CHANGELOG.md +5 -0
- data/Gemfile +10 -0
- data/Gemfile.lock +22 -0
- data/README.md +159 -0
- data/Rakefile +12 -0
- data/exe/marko +20 -0
- data/lib/assets/demo/README.md +13 -0
- data/lib/assets/demo/src/fr/assemble.md +27 -0
- data/lib/assets/demo/src/fr/compile.md +25 -0
- data/lib/assets/demo/src/fr/markup.md +111 -0
- data/lib/assets/demo/src/fr/storage.md +16 -0
- data/lib/assets/demo/src/fr/treenode.md +34 -0
- data/lib/assets/demo/src/index.md +34 -0
- data/lib/assets/demo/src/intro.md +98 -0
- data/lib/assets/demo/src/ui/cli.md +26 -0
- data/lib/assets/demo/src/ui/gem.md +14 -0
- data/lib/assets/demo/src/ur/uc.create.project.md +8 -0
- data/lib/assets/demo/src/ur/uc.general.flow.md +14 -0
- data/lib/assets/init/README.md +61 -0
- data/lib/assets/init/Rakefile +100 -0
- data/lib/assets/init/tt/artifact.md.tt +3 -0
- data/lib/marko/artifact.rb +3 -0
- data/lib/marko/assembler.rb +82 -0
- data/lib/marko/cli.rb +121 -0
- data/lib/marko/compiler.rb +16 -0
- data/lib/marko/config.rb +20 -0
- data/lib/marko/gadgets/pluggable.rb +55 -0
- data/lib/marko/gadgets/sentry.rb +66 -0
- data/lib/marko/gadgets/service.rb +52 -0
- data/lib/marko/gadgets.rb +3 -0
- data/lib/marko/loader.rb +38 -0
- data/lib/marko/markup/compiler.rb +36 -0
- data/lib/marko/markup/decorator.rb +65 -0
- data/lib/marko/markup/macro.rb +176 -0
- data/lib/marko/markup/parser.rb +122 -0
- data/lib/marko/markup/storage.rb +100 -0
- data/lib/marko/markup/validator.rb +101 -0
- data/lib/marko/markup.rb +24 -0
- data/lib/marko/parser.rb +19 -0
- data/lib/marko/services/assemble.rb +16 -0
- data/lib/marko/services/compile.rb +30 -0
- data/lib/marko/services.rb +2 -0
- data/lib/marko/storage.rb +36 -0
- data/lib/marko/tree_node.rb +128 -0
- data/lib/marko/validator.rb +19 -0
- data/lib/marko/version.rb +5 -0
- data/lib/marko.rb +37 -0
- data/marko.gemspec +44 -0
- metadata +99 -0
checksums.yaml
ADDED
@@ -0,0 +1,7 @@
|
|
1
|
+
---
|
2
|
+
SHA256:
|
3
|
+
metadata.gz: f907c502f514d2cd27122f2c2d6acf4e96c066515075c7b8df69b39c3022ee85
|
4
|
+
data.tar.gz: 075f639071daab8f53d56fec821196514f8c614c58b43b1cbc2306fc616f9f24
|
5
|
+
SHA512:
|
6
|
+
metadata.gz: fcdf1096aec13270c9a87ed229feda55c81e95de4073b7de264cb8b42dcd66ca2031f643bba63b40c9db2da2e83e945b817866589e4ecb3e2abebb04e2592ad3
|
7
|
+
data.tar.gz: df5ea3a5f9cdc378aee2bbe8292b3dc3d0e033da11a676a8fcaa5b5c294f614b0e23609ac6a633c79e1725ee9af462be1849a780ff4d1b45f1158ed417601f4e
|
data/CHANGELOG.md
ADDED
data/Gemfile
ADDED
data/Gemfile.lock
ADDED
@@ -0,0 +1,22 @@
|
|
1
|
+
PATH
|
2
|
+
remote: .
|
3
|
+
specs:
|
4
|
+
marko (0.1.0)
|
5
|
+
|
6
|
+
GEM
|
7
|
+
remote: https://rubygems.org/
|
8
|
+
specs:
|
9
|
+
minitest (5.16.3)
|
10
|
+
rake (13.0.6)
|
11
|
+
|
12
|
+
PLATFORMS
|
13
|
+
x64-mingw32
|
14
|
+
x86_64-linux
|
15
|
+
|
16
|
+
DEPENDENCIES
|
17
|
+
marko!
|
18
|
+
minitest (~> 5.0)
|
19
|
+
rake (~> 13.0)
|
20
|
+
|
21
|
+
BUNDLED WITH
|
22
|
+
2.4.1
|
data/README.md
ADDED
@@ -0,0 +1,159 @@
|
|
1
|
+
# Marko
|
2
|
+
|
3
|
+
Marko is a markup compiler that builds a tree from separated sources and compiles it into a single deliverable artifact.
|
4
|
+
|
5
|
+
Marko supplies a "docs-as-code" approach for compiling bulky software artifacts by providing source storage, original plain text markup, compiler templates, Ruby- and a command-line interface for assembling and compiling.
|
6
|
+
|
7
|
+
Having assembled the artifact, it can be analyzed, enriched by extra data, etc.; it can serve as a source for deriving subdued artifacts.
|
8
|
+
|
9
|
+
I've applied the approach for dozens of artifacts for the last six years, mainly writing requirements in Markdown, analyzing quality, deriving estimation sheets, exporting deliverables with Pandoc, and automating some parts of my everyday work.
|
10
|
+
|
11
|
+
## Installation
|
12
|
+
|
13
|
+
Install the gem by executing:
|
14
|
+
|
15
|
+
$ gem install marko
|
16
|
+
|
17
|
+
## Usage
|
18
|
+
|
19
|
+
### Interface
|
20
|
+
|
21
|
+
Marko provides just basic command-line interface for creating new projects and assembling artifacts - run `$ marko` to see the details.
|
22
|
+
|
23
|
+
In addition to the standard CLI, Marko supplies you with Rakefile, that also serves as custom automation example. You can run `rake -T` to see available commands.
|
24
|
+
|
25
|
+
To help you with task automation, Marko provides `Marko.assemble` for assembling and `Marko.compile` for compiling artifacts (you could already spot it inside Rakefile.) See [Automation](#automation) section for examples.
|
26
|
+
|
27
|
+
### Structure
|
28
|
+
|
29
|
+
`marko new PROJECT` command will create a new marko project inside the `PROJECT` directory with following structure:
|
30
|
+
|
31
|
+
- [bin/](bin/) - output folder for `build`
|
32
|
+
- [bin/assets/](bin/assets/) - assets folder
|
33
|
+
- [src/](src/) - markup sources
|
34
|
+
- [tt/](tt/) - templates for `build`
|
35
|
+
- [marko.yml](marko.yml) - project configuration
|
36
|
+
- [Rakefile](Rakefile) - Rake automation file
|
37
|
+
- [README.md](README.md) - this file
|
38
|
+
|
39
|
+
### Markup
|
40
|
+
|
41
|
+
The basic and the only Marko entity is [TreeNode](#github-link) with `id`, `meta`, `body`, and `items` properties.
|
42
|
+
|
43
|
+
And the primary activity is just writing source files consisting of the TreeNode, where the source actually just a regular Markdown with an optional metadata excerpt. All lines from `#` until the next `#` are considered TreeNode.
|
44
|
+
|
45
|
+
Let's see it by example and assume one has a few separate sources `content.md`, `uc.signup.md`, and `uc.signin.md`.
|
46
|
+
`content.md`
|
47
|
+
|
48
|
+
```markdown
|
49
|
+
# Overview
|
50
|
+
# User Requirements
|
51
|
+
## Use Cases
|
52
|
+
{{id: uc, order_index: .signup .signin}}
|
53
|
+
# Functional requirements
|
54
|
+
```
|
55
|
+
|
56
|
+
`uc.signup.md`
|
57
|
+
|
58
|
+
```markdown
|
59
|
+
# Sign-Up
|
60
|
+
{{id: .signup, parent: uc}}
|
61
|
+
|
62
|
+
body markup
|
63
|
+
```
|
64
|
+
|
65
|
+
`uc.signin.md`
|
66
|
+
|
67
|
+
```markdown
|
68
|
+
# Sign-In
|
69
|
+
{{id: .signin, parent: uc}}
|
70
|
+
|
71
|
+
body markup
|
72
|
+
```
|
73
|
+
|
74
|
+
These sources will be assembled in a single hierarchy as follows
|
75
|
+
|
76
|
+
```markdown
|
77
|
+
# Overview
|
78
|
+
# User Requirements
|
79
|
+
## Use Cases
|
80
|
+
{{id: uc, order_index: .signup .signin}}
|
81
|
+
### Sign-Up
|
82
|
+
{{id: .signup, parent: uc}}
|
83
|
+
|
84
|
+
body markup
|
85
|
+
### Sign-In
|
86
|
+
{{id: .signin, parent: uc}}
|
87
|
+
|
88
|
+
body markup
|
89
|
+
|
90
|
+
# Functional requirements
|
91
|
+
```
|
92
|
+
|
93
|
+
So all the assemblage magic is just linking TreeNode by using `id`, `parent`, and `order_index` attributes; where `id` and `parent` are just nodes identifiers, and `order_index` is just an array of identifiers that point out the order of getting `items`.
|
94
|
+
|
95
|
+
### Metadata
|
96
|
+
|
97
|
+
It was shown above how to provide hierarchy attributes by metadata excerpt `{{}}`. But you can also use the excerpt to provide your own attributes, like `source: John Doe`, `affects: some.other.thing`, etc.
|
98
|
+
|
99
|
+
### Tree, IDs
|
100
|
+
|
101
|
+
When you deal with trees in separated sources, to reference nodes you need identifiers. So when you write `id`, `parent` and `order_index` metadata - you actually deal with TreeNode Id, and it must be unique.
|
102
|
+
|
103
|
+
When one works on a simple parent -> child relationship, identifiers can be shortened by starting from `.`. In the example above `{{order_index: .signup .signin}}`, the parent will find its children by `/.signup$/` and `/.signin$/`; and besides, during the assembling phase those relative identifiers will be turned to full - `uc.signup` and `uc.signin`.
|
104
|
+
|
105
|
+
Marko will generate a unique Id for each TreeNode when Id was not provided by the author.
|
106
|
+
|
107
|
+
### Macros
|
108
|
+
|
109
|
+
The TreeNode.body can include macros. The most helpful one is `[[reference.id]]` that will be substituted by well-formed markdown link `[<node.title>](#<node.url>)`. There are also `@@tree`, `@@list`, `@@todo`, and `@@skip` standard macros; and this list could be extended or shortened through building templates.
|
110
|
+
|
111
|
+
- `@@tree` substituted by the tree of references to all descendants of the current node, might be used for the table of contents;
|
112
|
+
- `@@list` substituted by the list of references to node items;
|
113
|
+
- `@@todo` will will skip text with the macro till the end of the line
|
114
|
+
- `@@skip` will skip the text after the macro
|
115
|
+
|
116
|
+
### Templates
|
117
|
+
|
118
|
+
Marko uses templates placed under the `tt` folder to compile sources into artifacts. You can use and customize the default one or design your own for particular purposes. It's just pure ERB, where Marko enumerates TreeNodes and renders the node output.
|
119
|
+
|
120
|
+
```
|
121
|
+
<%= @node.header %>
|
122
|
+
<%= @node.meta %>
|
123
|
+
<%= @node.body %>
|
124
|
+
```
|
125
|
+
|
126
|
+
The `marko.yml` configuration file sets the building process's default template and other default values.
|
127
|
+
|
128
|
+
```yml
|
129
|
+
--- !ruby/struct:Marko::Artifact
|
130
|
+
id: ed863484-243f-4d46-8012-4b148f8c2910
|
131
|
+
title: Marko Artifact
|
132
|
+
template: tt/artifact.md.tt
|
133
|
+
filename: tt/marko-artifact.md
|
134
|
+
```
|
135
|
+
|
136
|
+
### Automation
|
137
|
+
|
138
|
+
Following quick example will assemble tree, remove TreeNode with id == 'hint', and compile the tree. You can also see Rakefile for other examples.
|
139
|
+
|
140
|
+
```ruby
|
141
|
+
require 'marko'
|
142
|
+
|
143
|
+
def do_remove_hint
|
144
|
+
tree = Marko.assemble
|
145
|
+
hint = tree.find_node('hint')
|
146
|
+
hint.orphan!
|
147
|
+
Marko.compile(tree: tree)
|
148
|
+
end
|
149
|
+
```
|
150
|
+
|
151
|
+
## Development
|
152
|
+
|
153
|
+
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
|
154
|
+
|
155
|
+
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and the created tag, and push the `.gem` file to [rubygems.org](https://rubygems.org).
|
156
|
+
|
157
|
+
## Contributing
|
158
|
+
|
159
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/marko.
|
data/Rakefile
ADDED
data/exe/marko
ADDED
@@ -0,0 +1,20 @@
|
|
1
|
+
#!/usr/bin/env ruby
|
2
|
+
|
3
|
+
require "bundler/setup"
|
4
|
+
require "marko"
|
5
|
+
include Marko
|
6
|
+
|
7
|
+
command = ARGV.shift
|
8
|
+
case command
|
9
|
+
when nil
|
10
|
+
CLI.banner
|
11
|
+
when /(n|new)/
|
12
|
+
dir = ARGV.shift
|
13
|
+
CLI.punch(dir)
|
14
|
+
when /(d|demo)/
|
15
|
+
CLI.punch_demo
|
16
|
+
when /(c|compile)/
|
17
|
+
CLI.compile
|
18
|
+
else
|
19
|
+
CLI.banner
|
20
|
+
end
|
@@ -0,0 +1,13 @@
|
|
1
|
+
% Marko Demo Project
|
2
|
+
|
3
|
+
# Overview
|
4
|
+
|
5
|
+
This project is an example of developing bulky technical artifacts with Marko Markup Compiler. It also serves as a sandbox for testing and features development.
|
6
|
+
|
7
|
+
# Usage
|
8
|
+
|
9
|
+
Run `$ marko` to see command-line interface
|
10
|
+
|
11
|
+
Run `$ rake marko:publish` to publish the aritfact
|
12
|
+
|
13
|
+
Run `$ rake -T` to see other custom interface
|
@@ -0,0 +1,27 @@
|
|
1
|
+
# Assemble artifact
|
2
|
+
{{id: .assemble, parent: fr}}
|
3
|
+
|
4
|
+
The system shall provide the function to assemble artifact.
|
5
|
+
|
6
|
+
__Input__
|
7
|
+
|
8
|
+
* NO
|
9
|
+
|
10
|
+
__Output__
|
11
|
+
|
12
|
+
Parameter Type 0..* Description
|
13
|
+
--------- -------- ---- --------------
|
14
|
+
tree TreeNode 1 assembled tree
|
15
|
+
|
16
|
+
__Flow__
|
17
|
+
|
18
|
+
@@todo provide id for required functions and change steps with appropriate links
|
19
|
+
|
20
|
+
1. get list of project sources
|
21
|
+
2. parse sources buffering nodes and errors
|
22
|
+
3. fail "parsing errors" if errors.any?
|
23
|
+
4. assemble artifact from buffer of nodes
|
24
|
+
5. generate and inject auto ids
|
25
|
+
6. validate artifact buffering errors
|
26
|
+
7. fail "tree errors" if errors.any?
|
27
|
+
8. return artifact
|
@@ -0,0 +1,25 @@
|
|
1
|
+
# Compile artifact
|
2
|
+
{{id: .compile, parent: fr}}
|
3
|
+
|
4
|
+
The system shall provide the function to create deliverable artifact.
|
5
|
+
|
6
|
+
__Input__
|
7
|
+
|
8
|
+
Parameter Type 0..* Description
|
9
|
+
--------- -------- ---- --------------
|
10
|
+
tree TreeNode 1 assembled tree
|
11
|
+
template String 1 ERB template
|
12
|
+
filename String 1 filename
|
13
|
+
|
14
|
+
__Output__
|
15
|
+
|
16
|
+
The output of the function must be well-formed deliverable with `filename` built on `template` parameter.
|
17
|
+
|
18
|
+
__Flow__
|
19
|
+
|
20
|
+
@@todo provide id for required functions and change steps with appropriate links
|
21
|
+
|
22
|
+
1. `tree` = [[fr.assemble]] unless `tree`
|
23
|
+
2. load template body from `template`
|
24
|
+
3. backup `filename` to `<filename>~`
|
25
|
+
4. render `template` for each node of `tree` into `filename`
|
@@ -0,0 +1,111 @@
|
|
1
|
+
# Source Markup
|
2
|
+
{{id: .markup, parent: fr}}
|
3
|
+
|
4
|
+
The main and only entity in the system is [[fr.treenode]]. The system shall provide the following abilities for the entity:
|
5
|
+
|
6
|
+
@@list
|
7
|
+
|
8
|
+
## Node Markup
|
9
|
+
{{id: .node}}
|
10
|
+
|
11
|
+
The system shall support the following node markup.
|
12
|
+
|
13
|
+
```markdown
|
14
|
+
# <title>
|
15
|
+
{{\<meta\>}}
|
16
|
+
\<body\>
|
17
|
+
```
|
18
|
+
|
19
|
+
Where:
|
20
|
+
|
21
|
+
- Each node starts from Markdown header mark `#`.
|
22
|
+
- The header mark can be followed by node title.
|
23
|
+
- The next line _might_ contain metadata block:
|
24
|
+
- that starts from `{{` and finishes with `}}`;
|
25
|
+
- that can be one or multiline string.
|
26
|
+
- The next lines tile the end of file or next header mark `#` are considered as node body.
|
27
|
+
|
28
|
+
## Get Sources
|
29
|
+
|
30
|
+
The system shall provide function to getting all sources files from project repository.
|
31
|
+
|
32
|
+
@@todo define project repository
|
33
|
+
|
34
|
+
## Parse Source
|
35
|
+
|
36
|
+
The system shall provide the function to parse source file.
|
37
|
+
|
38
|
+
During the parsing process the system must record source information within the node parsed, such as origin file name and the number of line inside the origin where the node begins. This information must be stored inside metadata as [[fr.treenode.orig]].
|
39
|
+
|
40
|
+
__Input__
|
41
|
+
|
42
|
+
Parameter Type 0..* Description
|
43
|
+
--------- ------ ---- -----------
|
44
|
+
filename String 1 filename
|
45
|
+
|
46
|
+
__Output__
|
47
|
+
|
48
|
+
Parameter Type 0..* Description
|
49
|
+
--------- ------ ---- -----------
|
50
|
+
node Node 0..n node parsed
|
51
|
+
|
52
|
+
## Assemble Tree
|
53
|
+
|
54
|
+
The system shall provide the function to assemble the artifact tree. The artifact tree is assembled based on [[fr.treenode.tree]].
|
55
|
+
|
56
|
+
@@todo The assemblage algorithm, errors handler
|
57
|
+
|
58
|
+
__Input__
|
59
|
+
|
60
|
+
Parameter Type 0..* Description
|
61
|
+
--------- ------ ---- -----------
|
62
|
+
node Node 0..n node array
|
63
|
+
|
64
|
+
__Output__
|
65
|
+
|
66
|
+
Parameter Type 0..* Description
|
67
|
+
--------- ------ ---- -----------
|
68
|
+
node Node 1 root tree
|
69
|
+
|
70
|
+
## Inject Id
|
71
|
+
|
72
|
+
The system shall provide each node with unique node Id.
|
73
|
+
|
74
|
+
Some nodes can already have ids from source file, especially those that referenced as parent or child and placed in separate files. For those nodes that still have empty id, the system must generate auto id 0..99.
|
75
|
+
|
76
|
+
For example, when the system has assembled the tree
|
77
|
+
|
78
|
+
```markdown
|
79
|
+
# Artifact
|
80
|
+
## Introduction
|
81
|
+
### Purpose
|
82
|
+
### Scope
|
83
|
+
# User Requirements #ur
|
84
|
+
# Functional Requirements #fr
|
85
|
+
```
|
86
|
+
|
87
|
+
and then generated id, the generated ids should be as follows:
|
88
|
+
|
89
|
+
```markdown
|
90
|
+
# Artifact Title #00
|
91
|
+
## Introduction #01.01
|
92
|
+
### Purpose #01.01.01
|
93
|
+
### Scope #01.01.02
|
94
|
+
# User Requirements #ur
|
95
|
+
# Functional Requirements #fr
|
96
|
+
```
|
97
|
+
|
98
|
+
__Input__
|
99
|
+
|
100
|
+
Parameter Type 0..* Description
|
101
|
+
--------- ------ ---- -----------
|
102
|
+
root Node 1 root node
|
103
|
+
|
104
|
+
## Checking Tree
|
105
|
+
|
106
|
+
The system shall provide the function to check assembled tree for errors related to assembling tree based on [[fr.treenode.tree]]. The system must check the following errors:
|
107
|
+
|
108
|
+
- `duplicate id`, finds two or more nodes that share the same id;
|
109
|
+
- `unknown parent`, finds nodes that have `parent` metadata, but parent not found in the tree;
|
110
|
+
- `unknown index`, finds nodes with `order_index` metadata where one or more children in the index not found;
|
111
|
+
- `unknown links`, finds nodes containing links but the links are not found.
|
@@ -0,0 +1,16 @@
|
|
1
|
+
# Sources Storage
|
2
|
+
{{id: .storage, parent: fr}}
|
3
|
+
|
4
|
+
The system shall provide a storage for artifact sources. The storage must provide the following features:
|
5
|
+
|
6
|
+
- Create a new project
|
7
|
+
- Remove project
|
8
|
+
- Get the list of project sources
|
9
|
+
- Get project source
|
10
|
+
|
11
|
+
@@skip
|
12
|
+
|
13
|
+
At this stage only option will be developed - the filesystem storage. Other options that should be considered for future stages are
|
14
|
+
|
15
|
+
- Database storage (SQL and NoSQL)
|
16
|
+
- Confluence Wiki
|
@@ -0,0 +1,34 @@
|
|
1
|
+
# TreeNode
|
2
|
+
{{id: .treenode, parent: fr}}
|
3
|
+
|
4
|
+
The system shall provide `Node` entity with the following properties that provide the following attributes:
|
5
|
+
|
6
|
+
Property Type *..n Default Description
|
7
|
+
--------- ------ ---- ------- -----------
|
8
|
+
id String 1 "" Node identifier
|
9
|
+
parent Node 1 null Parent node reference
|
10
|
+
title String 1 "" Node title
|
11
|
+
meta Hash 1 {} Node metadata
|
12
|
+
body String 1 "" Node body
|
13
|
+
items Node 0..n [] Child node reference
|
14
|
+
|
15
|
+
## Tree Metadata
|
16
|
+
{{id: .tree}}
|
17
|
+
|
18
|
+
To assemble the project artifact from nodes placed among several source files, the system shall provide the following optional tree metadata attributes:
|
19
|
+
|
20
|
+
Attribute Type 0..n Description
|
21
|
+
----------- ------ ---- --------------
|
22
|
+
id String 0..1 Unique node id
|
23
|
+
parent String 0..1 Parent id
|
24
|
+
order_index String 0..1 Children ids delimited by space
|
25
|
+
|
26
|
+
## Source Metadata
|
27
|
+
{{id: .orig}}
|
28
|
+
|
29
|
+
During source file parsing, the system must store the following node origin information:
|
30
|
+
|
31
|
+
Attribute Type 0..n Description
|
32
|
+
----------- ------ ---- --------------
|
33
|
+
origin String 1 Source filename
|
34
|
+
lineno String 1 Number of line
|
@@ -0,0 +1,34 @@
|
|
1
|
+
# Intro
|
2
|
+
{{id: intro}}
|
3
|
+
|
4
|
+
# Users
|
5
|
+
{{id: usr}}
|
6
|
+
|
7
|
+
The users of the system are different people who play for authoring various sorts of technical documentation. It might be a technical writer, business/systems analyst, developer, etc.
|
8
|
+
|
9
|
+
# User Requirements
|
10
|
+
{{id: ur, order_index: uc}}
|
11
|
+
|
12
|
+
## Use Cases
|
13
|
+
{{id: uc, order_index: .create.project .general.flow}}
|
14
|
+
|
15
|
+
# Functional Requirements
|
16
|
+
{{id: fr, order_index: .treenode .markup .storage .assemble .compile}}
|
17
|
+
|
18
|
+
# Interface Requirements
|
19
|
+
{{id: ui, order_index: .cli .gem}}
|
20
|
+
|
21
|
+
# Assumptions and Dependencies
|
22
|
+
{{id: as}}
|
23
|
+
|
24
|
+
##
|
25
|
+
|
26
|
+
The system requires a user interface for managing markup sources. It is assumed that users utilize any text editor of their choice.
|
27
|
+
|
28
|
+
##
|
29
|
+
|
30
|
+
The system requires tools for collaboration on artifacts by several authors simultaneously. Because of the plain text nature of the markup sources, It is assumed using Git for managing the artifact sources repository.
|
31
|
+
|
32
|
+
##
|
33
|
+
|
34
|
+
The system requires the compilation of artifacts into deliverables in form of well-supported formats like pdf, doc, etc. It is assumed using Pandoc for creating deliverables.
|
@@ -0,0 +1,98 @@
|
|
1
|
+
# Purpose
|
2
|
+
{{parent: intro}}
|
3
|
+
|
4
|
+
The main purpose of this document is to provide a comprehensive demo project for Marko gem. The other technical purpose is to have Marko Sandbox for testing and development.
|
5
|
+
|
6
|
+
# Problem
|
7
|
+
{{parent: intro}}
|
8
|
+
|
9
|
+
There are a few alternatives for authors who work on bulky software artifacts like requirements specification. They can apply one of the following tools
|
10
|
+
|
11
|
+
@@todo find a few popular requirements management tools
|
12
|
+
@@todo find a few popular Tex alternatives
|
13
|
+
|
14
|
+
- a particular requirements management tool, like Doors
|
15
|
+
- a Word Processor, like Microsoft Word, Libra Office, or Google Docs;
|
16
|
+
- an elaborate publishing system, like Tex;
|
17
|
+
- or just using a simple Wiki system, like Confluence or Redmine.
|
18
|
+
|
19
|
+
A requirements management tool might seem to be the best choice there because it is tailored exactly for the required process. But it certainly will be a "hard way" from a cost and time perspective, an elaborate and expensive solution requiring personnel to be trained and vendor support.
|
20
|
+
|
21
|
+
Although deliverable artifacts could be seen as a usual document structured and expressed in headers and paragraphs, the meaning of each of those can be different. So word processors and wiki systems might be the perfect choice for presenting artifact deliverables, but they lack of semantic fails for content development and management. The best of them provide a scripting language for document processing, but it is usually too complicated and again lacks particular entities' semantics (stakeholders, requirements, constraints, etc.)
|
22
|
+
|
23
|
+
Designing documents of hundreds of pages in word processors brings some peculiar drawbacks. The software tends to become "bulky" in operating, consuming too many system resources and responding with delays; tend to be fragile with styles.
|
24
|
+
|
25
|
+
__The problem of__ the lack of simple tools and approaches for writing software artifacts __affects__ technical writers who develop and manage the artifacts __the impact of which is__ they tend to choose a publishing tool or a word processor that does not fit well to work on software artifacts causing lots of manual work and maybe other confusing things like "bulky" documents __a successful solution would be__ the tool that will provide
|
26
|
+
|
27
|
+
- a plain text markup for writing artifact items, that will be easy to read for humans, and processed by machines;
|
28
|
+
- a "semantics" layer to distinguish artifact items (actors, requirements, etc.) from supported text
|
29
|
+
- the ability to automate tasks based on processing content according to its semantic value;
|
30
|
+
- the ability to build a convenient presentation of the artifact (pdf, doc, odt);
|
31
|
+
- will not depend on OS platform and any proprietary format or software.
|
32
|
+
|
33
|
+
@@skip
|
34
|
+
|
35
|
+
It provides a statement summarizing the problem being solved by the project.
|
36
|
+
|
37
|
+
__The problem of__ [describe the problem]
|
38
|
+
__affects__ [the stakeholders affected by the problem]
|
39
|
+
__the impact of which is__ [what is the impact of the problem?]
|
40
|
+
__a successful solution would be__ [list some key benefits of a successful solution]
|
41
|
+
|
42
|
+
# Product
|
43
|
+
{{parent: intro}}
|
44
|
+
|
45
|
+
@@todo redesign the product statement for "who" section
|
46
|
+
|
47
|
+
__For__ authors of software artifacts __who__ need a reliable and repeatable process of managing big software artifacts __the__ Marko Markup Compiler is a free open source software __that__ brings a "docs-as-code" approach with efficient plain markup for artifact sources, @@todo templates, CLI, Rake ..
|
48
|
+
|
49
|
+
@@skip
|
50
|
+
|
51
|
+
__For__ [target customer]
|
52
|
+
__Who__ [statement of the need or opportunity]
|
53
|
+
__The__ [product name] is a [product category]
|
54
|
+
__That__ [key benefit, compelling reason to buy]
|
55
|
+
__Unlike__ [primary competitive alternative]
|
56
|
+
__Our product__ [statement of primary differentiation]
|
57
|
+
|
58
|
+
# Scope
|
59
|
+
{{parent: intro}}
|
60
|
+
|
61
|
+
The developing system will consist of
|
62
|
+
|
63
|
+
- the simple plain markup for writing the artifact sources;
|
64
|
+
- the repository of artifact sources;
|
65
|
+
- the algorithm for assembling the artifact from sources;
|
66
|
+
- the markup for templates for publishing the artifact;
|
67
|
+
- the command line interface for compiling the artifact into deliverables based on the templates
|
68
|
+
- the Ruby Gem that presents the artifact as the collection o items that can be easily visited for tasks automation;
|
69
|
+
- the demo project that will help the customers to adopt the approach and design their own solutions based on the approach.
|
70
|
+
|
71
|
+
# Definitions
|
72
|
+
{{parent: intro}}
|
73
|
+
|
74
|
+
CLI
|
75
|
+
|
76
|
+
: Command-line interface
|
77
|
+
|
78
|
+
ERB
|
79
|
+
|
80
|
+
: Ruby Templating system
|
81
|
+
|
82
|
+
# References
|
83
|
+
{{parent: intro}}
|
84
|
+
|
85
|
+
1. [Markdown Guide](https://www.markdownguide.org/)
|
86
|
+
2. [Pandoc User's Guide](https://pandoc.org/MANUAL.html)
|
87
|
+
3. [Git User's Manual](https://git-scm.com/docs/user-manual.html)
|
88
|
+
|
89
|
+
# Overview
|
90
|
+
{{parent: intro}}
|
91
|
+
|
92
|
+
The remaining sections of this document provide user- and functional requirements of the system.
|
93
|
+
|
94
|
+
The [[usr]] chapter introduces users of the system.
|
95
|
+
|
96
|
+
The next chapter [[ur]] introduces users requirements that establish the context for the functional requirements.
|
97
|
+
|
98
|
+
The following chapter [[fr]] describes detailed requirements for functions and user interfaces.
|
@@ -0,0 +1,26 @@
|
|
1
|
+
# Command-line interface
|
2
|
+
{{id: .cli, parent: ui}}
|
3
|
+
|
4
|
+
The system shall provide a command-line interface. The interface must provide the following commands:
|
5
|
+
|
6
|
+
@@list
|
7
|
+
|
8
|
+
## Create a new project
|
9
|
+
|
10
|
+
The system shall provide the `new PROJECT` command. When the user requests the `new PROJECT` command, the system
|
11
|
+
|
12
|
+
- ensures that `PROJECT` folder does not exist or fails
|
13
|
+
- creates `PROJECT` folder and copies required files for new project
|
14
|
+
- reports the user about success
|
15
|
+
|
16
|
+
## Compile artifact
|
17
|
+
|
18
|
+
The system shall provide the `compile [-t TEMPALTE] [-o FILENAME]` command. When the user requests the `compile` command, the system
|
19
|
+
|
20
|
+
- ensures that current directory is `Marko Project` directory, or fails
|
21
|
+
- load `template`,
|
22
|
+
- load from the `TEMPLATE` parameter when provided
|
23
|
+
- or load default template when not
|
24
|
+
- creates `tree` by using [[fr.assemble]]
|
25
|
+
- compiles the tree by [[fr.compile]].(`tree`, `template`, `filename`)
|
26
|
+
- reports the user about success
|
@@ -0,0 +1,8 @@
|
|
1
|
+
# Create a new project
|
2
|
+
{{id: uc.create.project, parent: uc}}
|
3
|
+
|
4
|
+
__Main Flow__
|
5
|
+
|
6
|
+
1. The user requests the system to create a new project passing a project folder for new project.
|
7
|
+
2. The system checks for project folder to be unique. When folder with the same name exists already, the system reports it to the user and the scenario is finished.
|
8
|
+
3. The system creates the project folder and furnish it with project structure.
|
@@ -0,0 +1,14 @@
|
|
1
|
+
# General Clerq flow
|
2
|
+
{{id: uc.general.flow, parent: uc}}
|
3
|
+
|
4
|
+
__Prerequisites__
|
5
|
+
|
6
|
+
1. The user inside Marko project (see [[uc.create.project]])
|
7
|
+
|
8
|
+
__Main Flow__
|
9
|
+
|
10
|
+
1. The user creates and makes changes to the sources of the project. [outside the system]
|
11
|
+
2. The user requests the system to `compile` the artifact.
|
12
|
+
3. The system assembles the artifact from source files.
|
13
|
+
4. The system checks the artifact and reports the errors to the user if any.
|
14
|
+
5. The system returns the assembled artifact.
|