A command-line tool for working with a log of Architecture Decision Records (ADRs).
An Architectural Decision (AD) is a justified design choice that addresses a functional or non-functional requirement that is architecturally significant. An Architecturally Significant Requirement (ASR) is a requirement that has a measurable effect on the architecture and quality of a software and/or hardware system. An Architectural Decision Record (ADR) captures a single AD and its rationale; the collection of ADRs created and maintained in a project constitute its decision log. All these are within the topic of Architectural Knowledge Management (AKM), but ADR usage can be extended to design and other decisions (“any decision record”).
The aim of the GitHub adr organization is to:
- Motivate the need for and benefits of AD capturing and establish a common vocabulary.
- Strengthen the tooling around ADRs, in support of agile practices as well as iterative and incremental engineering processes.
- Provide pointers to public knowledge in the context of AKM and ADRs.
The repository for the Website of the ADR organization is https://github.com/adr/adr.github.io.
Das agile Manifest für Software-Entwicklung hat die Dokumentation nicht ohne Grund auf die rechte Seite gestellt: „Working software over comprehensive documentation.“
Eine leichtgewichtige und daher schnelle Dokumentation ermöglicht die agile Praxis der Architectural Decisions Records.
Längst wird das Konzept, Infrastruktur und Konfigurationen textuell in Form von Code zu beschreiben und zu versionieren, großflächig in Projekten eingesetzt. Auch deshalb entstand ein Ökosystem an Tools und Frameworks, die die Möglichkeit bieten, mittels einer DSL oder gar Programmiersprachen wie Java, Python oder TypeScript Infrastruktur zu programmieren. Durch Infrastruktur-Code ergeben sich viele Vorteile wie Wiederverwendbarkeit einzelner Komponenten, verbesserte Konsistenz, Erhöhung des Automatisierungsgrades im Projekt, sowie Transparenz gegenüber dem reinen Konfigurieren per Oberfläche.
Antora’s site generator handles all aspects of creating a documentation site, from fetching and aggregating to converting and arranging the content to publishing the files of the generated site. This page describes that process in detail.
The default pipeline is opinionated to get you started as quickly as possible. But understand that Antora features a modular, open architecture. That means this architecture can accommodate specialized use cases by allowing custom Antora components, such as a validators, to be inserted into the pipeline at strategic points as needed. This page focuses on the core, built-in Antora components and capabilities in Antora.
Antora collects and processes content source files according to a set of hierarchical files and directories it expects to find at a content source root. This page introduces this hierarchy, the reserved directory and file names it employs, and the rules about which files get collected or ignored.
Antora employs both convention and configuration to aggregate content and generate your site. Before setting up or migrating your repositories, let’s review some key concepts that could impact how you organize your documentation projects and content files to work with Antora.
Python environment tools for Visual Studio Code
Performant Python environment tooling and support, such as locating all global Python installs and virtual environments.
Environment Types Supported
- python.org
- Windows Store
- PyEnv
- PyEnv-Win
- PyEnv-Virtualenv
- Conda
- Miniconda
- Miniforge
- PipEnv
- Homebrew
- VirtualEnvWrapper
- VirtualEnvWrapper-Win
- Venv
- VirtualEnv
- Python on your PATH
Features
- Discovery of all global Python installs
- Discovery of all Python virtual environments
This plugin is designed to help to publish your Antora docs into Confluence. The main reason is, that we want to have a single source of truth for our documentation. We want to write our documentation in AsciiDoc and publish it to Confluence as some of our Stakeholders are using Confluence.
The captain offers the following options:
- Publish your whole Antora docs to Confluence
- Publish only selected pages/ folders, by using filters
- Control where the docs should be published by setting an
overall parent page in Confluence - Decide if you want to inform your readers that those pages are
- generated by automation by applying a banner.
You’d think an intuitive system for creating links between pages would be a central feature of every site generator. After all, that’s kind of what the web is all about. Sadly, it’s often an afterthought.
The current mechanisms tend to distract from writing. Each time you want to make a link to another page, you have to pause to compute a relative path and/or transform the path to a published URL in your head. If you move the page you’re editing, it may cause the relative path to shift, which means you have to go back and recompute those references.
It’s no wonder writers create broken links at an alarming rate or spend excessive amounts of time fixing broken links left behind by other writers. But we can’t fault the writers when it’s the system itself that’s broken. Let’s figure out a solution.
In a previous article, we established that content is sovereign, which means the site generator needs to gather content from various repositories and branches. In order for the generator to identify, aggregate, and catalog content partitioned in this way, the repositories must present a consistent structure. Otherwise, the generator isn’t going to know which files represent pages or which pages should be grouped together.
Ship your documentation as fast as your product.
We provide tools and workflows that help teams coordinate documentation initiatives across products and departments.
The table below shows the full list of languages (and corresponding classes/aliases) supported by Highlight.js. Languages that list a Package below are 3rd party languages and are not bundled with the core library. You can find their repositories by following the links.
Note: The languages available will depend on how you’ve built or are included the library in your app. For example our default minified web build includes only ~40 popular languages. See Getting the Library and Importing the Library in the README for examples of how to load additional/specific languages.
OpenSearch is a community-driven, open source fork of Elasticsearch and Kibana following the license change in early 2021. We're looking to sustain (and evolve!) a search and analytics suite for the multitude of businesses who are dependent on the rights granted by the original, Apache v2.0 License.
Learn to use OpenSearch, the highly scalable and extensible open-source software suite for search, analytics, observability, and other data-intensive applications.
Welcome to ISC's Knowledgebase!
This site is intended to provide answers to many of the questions users may have about our open source software products: BIND 9, ISC DHCP, and Kea DHCP.
In this About ISC section, you'll find some general information that applies to all of our software. In the BIND 9, ISC DHCP, and Kea DHCP sections, you'll find lots of detailed information and helpful tips to make your network administration easier. Feel free to browse through everything, or use the search function to find articles on a specific topic of interest to you.
If you need more help than this Knowledgebase can provide, please consider joining one of our user mailing lists. These open fora offer best-effort support from other users of our software.
If mission-critical DNS and DHCP operations are important to you, we offer high-quality support from our team of experienced engineers as a paid service. Paid support contracts give ISC the funds we need to continue developing open source software that benefits the entire Internet. Please visit the Contact page on our main website for more details.
Thank you very much for using ISC's software! For more than 25 years, we have been here to serve the community and keep the Internet safe and accessible to all. To find out more about us, please visit our website at https://www.isc.org.
Kea currently supports 198 commands in kea-ctrl-agent, kea-dhcp-ddns, kea-dhcp4, kea-dhcp6 daemons and cb_cmds, class_cmds, gss_tsig, high_availability, host_cache, host_cmds, lease_cmds, lease_query, perfmon, stat_cmds, subnet_cmds hook libraries.
Kea Features
- Separate DHCPv4, DHCPv6 and Dynamic DNS servers (run only the applications you are using)
- Leases and host reservations can be stored in a local file (default) or optionally in a MySQL, Postgres or Cassandra database
- IPv6 prefix delegation
- Most popular options supported, including PXE boot
- Shared networks
- Applications API, with multiple application extensions available from ISC
- On-line configuration. It is possible to update the configuration file and tell the servers to reload configuration without restarting the system.
- Ample, documented statistics
- REST api for remote management
- High performance, with up to ~5000 leases per second (default), ~500 leases per second (with optional database backend)
- Supported on Linux, BSD and Mac OS X operating systems
Kea is the next generation of DHCP software, developed by Internet Systems Consortium (ISC). It supports both the DHCPv4 and DHCPv6 protocols along with their extensions, e.g. prefix delegation and dynamic updates to DNS.
This guide covers Kea version 2.7.1-git.