-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
govuk-form-builder
A form builder for Ruby on Rails that’s compatible with the GOV.UK Design System.
-
-
scripts-to-rule-them-all
Discontinued Set of boilerplate scripts describing the normalized script pattern that GitHub uses in its projects.
I use documentation systems that publish the documentation from the repo to a website. Most of my projects use Sphinx and reStructuredText for this, but I recently tried MyST (Markdown for Sphinx) and I like that a lot.
Some examples:
- https://docs.datasette.io serves documentation from https://github.com/simonw/datasette - which has documentation unit tests here: https://github.com/simonw/datasette
- https://django-sql-dashboard.datasette.io/ serves from markdown in https://github.com/simonw/django-sql-dashboard - I don't have documentation unit tests for that yet
I use documentation systems that publish the documentation from the repo to a website. Most of my projects use Sphinx and reStructuredText for this, but I recently tried MyST (Markdown for Sphinx) and I like that a lot.
Some examples:
- https://docs.datasette.io serves documentation from https://github.com/simonw/datasette - which has documentation unit tests here: https://github.com/simonw/datasette
- https://django-sql-dashboard.datasette.io/ serves from markdown in https://github.com/simonw/django-sql-dashboard - I don't have documentation unit tests for that yet
This is definitely the best approach in my opinion, providing the people writing the docs are capable of contributing directly.
One of my projects[0] builds and deploys a static documentation site[1] on every push to master. The static site generator (Nanoc, in this case) then pulls in the library and uses it to publish its own documentation. All the examples are snippets of code[2] that are both displayed as-is and eval'd into the final output.
The guide can never be out of sync with the library.
[0] https://github.com/dfe-digital/govuk_design_system_formbuild...
[1] https://govuk-form-builder.netlify.app/
[2] https://github.com/DFE-Digital/govuk_design_system_formbuild...
This is definitely the best approach in my opinion, providing the people writing the docs are capable of contributing directly.
One of my projects[0] builds and deploys a static documentation site[1] on every push to master. The static site generator (Nanoc, in this case) then pulls in the library and uses it to publish its own documentation. All the examples are snippets of code[2] that are both displayed as-is and eval'd into the final output.
The guide can never be out of sync with the library.
[0] https://github.com/dfe-digital/govuk_design_system_formbuild...
[1] https://govuk-form-builder.netlify.app/
[2] https://github.com/DFE-Digital/govuk_design_system_formbuild...
You can use the CI to publish you md files with tools like https://docusaurus.io/
GitHub have a pattern for this called "scripts to rule them all" - https://github.com/github/scripts-to-rule-them-all - I've not fully adopted it yet but I probably should, it looks very well thought-out.