Das deutschsprachige Forth Magazin Vierte Dimension (4D) erscheint 4x im Jahr1). Vorbild war zunächst die amerikanische "Forth Dimensions". Ihr VOLUME 1, NO. 1 begann 1978 mit der Frage: „What is the Forth Interest Group?“. Nach 21 Volumes war dann 1999 Schluß.
Unser Blatt gibt es nun seit 1984, und umfasst schon 37 Jahrgänge2). Inzwischen sind wir das einzige Forth Magazin weltweit. Seit einigen Jahren publizieren wir auch in englischer Sprache. Hier nun das komplette Archiv des Magazins im PDF-Format.
UEFI based x86-64 Forth
Naive linter for English prose for developers who can't write good and wanna learn to do other stuff good too.
Detect non-inclusive language in your source code.
Vale is an open-source, command-line tool (, , and ) that brings your editorial style guide to life.
I had been a user of mutt since 1996 when it had just been created by Michael Elkins. In June 2016 I learned about "neomutt". And i think it it the way to go now.. this page: http://www.guckes.net/neomutt/ http://www.guckes.net/neomutt/index.txt the source.. no colours ;) here i document my findings along the way to move from mutt to neomutt.
tmate is a fork of tmux. tmate and tmux can coexist on the same system.
When NeoMutt starts up it looks for two configuration files – one “ system” file and one “ user” file.
NeoMutt first reads the system configuration file, then the user configuration file. The two files are merged in the sense that "last setting wins". That is, if a setting is defined in both files, the user configuration file's value for that setting is the one that takes precedence and becomes effective.
NeoMutt searches for several different file names when looking for config. It looks for NeoMutt config files before Mutt config files and versioned config before plain config.
This section provides a quick glimpse into the expressive power of YAML. It is not expected that the first-time reader grok all of the examples. Rather, these selections are used as motivation for the remainder of the specification.
The pytest framework makes it easy to write small, readable tests, and can scale to support complex functional testing for applications and libraries.
pytest requires: Python 3.7+ or PyPy3.
%YAML 1.2
YAML: YAML Ain't Markup Language™
YAML Resources:
YAML Specifications:
- YAML 1.2:
- Revision 1.2.2 # Oct 1, 2021 New
- Revision 1.2.1 # Oct 1, 2009
- Revision 1.2.0 # Jul 21, 2009
- YAML 1.1
- YAML 1.0
YAML (/ˈjæməl/) (see § History and name) is a human-readable data-serialization language. It is commonly used for configuration files and in applications where data is being stored or transmitted. YAML targets many of the same communications applications as Extensible Markup Language (XML) but has a minimal syntax which intentionally differs from Standard Generalized Markup Language (SGML).[1] It uses both Python-style indentation to indicate nesting, and a more compact format that uses [...] for lists and {...} for maps[1] thus JSON files are valid YAML 1.2.[2]
When NeoMutt starts up it looks for two configuration files – one “ system” file and one “ user” file.
NeoMutt first reads the system configuration file, then the user configuration file. The two files are merged in the sense that "last setting wins". That is, if a setting is defined in both files, the user configuration file's value for that setting is the one that takes precedence and becomes effective.
NeoMutt searches for several different file names when looking for config. It looks for NeoMutt config files before Mutt config files and versioned config before plain config.
When I say "Legacy Code" I mean valuable code you're afraid to change.
We all have to deal with Legacy Code. But it's damn hard to!
Here you'll find answers to your questions. I'm sharing useful tips and concrete advice that will help you tame the legacy codebase you've inherited.
Change Messy Software Without Breaking It
In this tutorial, you’ll learn how to quickly build documentation for a Python package using MkDocs and mkdocstrings. These tools allow you to generate nice-looking and modern documentation from Markdown files and your code’s docstrings.
Maintaining auto-generated documentation means less effort because you’re linking information between your code and the documentation pages. However, good documentation is more than just the technical description pulled from your code! Your project will appeal more to users if you guide them through examples and connect the dots between the docstrings.
The Material for MkDocs theme makes your documentation look good without any extra effort and is used by popular projects such as Typer CLI and FastAPI.
There are several different docstring formats which one can use in order to enable Sphinx’s autodoc extension to automatically generate documentation. For this tutorial we will use the Sphinx format, since, as the name suggests, it is the standard format used with Sphinx. Other formats include Google (see here) and NumPy (see here), but they require the use of Sphinx’s napoleon extension, which is beyond the scope of this tutorial.
The Diátaxis framework aims to solve the problem of structure in technical documentation. It adopts a systematic approach to understanding the needs of documentation users in their cycle of interaction with a product.
The name Diátaxis comes from the Ancient Greek δῐᾰ́τᾰξῐς: dia (“across”) and taxis (“arrangement”).
Diátaxis identifies four modes of documentation - tutorials, how-to guides, technical reference and explanation. It derives its structure from the relationship between them.
In Diátaxis, each of these modes (or types) answers to a different user need, fulfils a different purpose and requires a different approach to its creation.
Do you document your code? Imagine that you need to get back to your code in 6 month after you wrote it, there is always a big possibility that you will have to spend some time to find out how this code works. Or if someone else wrote some code, which is already in production and your task is to fix a bug in it and there is no documentation and no one actually knows what this code does.
There are more benefits of implementing continuous documentation for the code:
easy to onboard new team members,
easy to share knowledge,
if this code is open source - easy to start contributing,
easy to see purpose and motivation of each piece of code,
easy to keep versioning for each new release of the code.It this talk I will show the difference between documentation types and will show a demo in the end of the talk.
