Imagine a schema for defining expected directory/file structures for your applications.
Define it all in YAML, then use a proper library to:
validate an existing path structure against your schema
generate model folder/file trees in arbitrary or logical order
document your expected path structure based on properties of each dir/file key
Take a look at the following example schema.
| { | |
| "Pet": { | |
| "type": "object", | |
| "required": [ | |
| "name", | |
| "photoUrls" | |
| ], | |
| "properties": { | |
| "id": { | |
| "type": "integer", |
(tested on PopOS 19.04)
Download linux archive from Bibisco.
Move files to better path.
sudo mv ~/Downloads/bibisco-blah-blah/ ~/opt/bibisco
| # Fusuma makes Linux touchpads better | |
| # See https://github.com/iberianpig/fusuma | |
| swipe: | |
| 3: | |
| left: | |
| command: 'xdotool key alt+Right' | |
| right: | |
| command: 'xdotool key alt+Left' | |
| up: | |
| command: 'xdotool key super' |
| # See README.adoc |
| See README.adoc |
There are 28 static site generators that support AsciiDoc sourcing.
Copies content/ to _build/, without carrying the parent directory.
Copies theme/ to _build/.
Performs the first round of product-data parsing to build two structurally vital files, sourcing data in data/product.yml.
Builds the page metadata (_build/includes/_built_page-meta.adoc) included in all HTML and PDF exposures of topics, but only relevant as Jekyll page metadata at this time.
Builds the metadata file _build/includes/_built_page-meta.adoc based on the user stories in product.yml, looping over them as directed in _templates/liquid/page-meta.asciidoc. The topics metadata is drawn from this preprocessed file (_build_page-meta.adoc).
Draws data from the `data/meta.yml`and parses it as follows:
Builds _build/includes/_built_company-info.adoc pressed with the template _templates/liquid/company-info.asciidoc.
Draws data from the `data/terms.yml`and parses it as follows:
