FlorianHeigl/gist:aae80d96afba43feb6866cfb504ab40c

## gistfile1.txt
##############
State Machines
##############


Finite State Machines und davon abgeleitetes Anwendungsdesign sind das, was viele Industrie-Systeme robust macht.
Jede TCP Connection, jede SMTP Übertragung durchläuft eine protokollseitige State Machine.
In Software findet man sie als Grundlage vieler moderner Anwendungen im Cloud-Bereich.
CFEngine ist darauf aufgebaut, ebenso kommerzielle Cluster wie VCS (alle Monitor Agents von VCS sind State Machines).

Finite State Machines dienen als Abstraktionsebene, diese ermöglicht IMMER einen definierten Zustand zu erreichen.


##############################################
Buchreferenzen und Historie von State Machines
##############################################


Grundsätzlich behandelt jedes Buch zu Algorithmen / Informatik wohl auch State Machines.
Schwieriger ist es, praxistaugliche Erläuterungen zu finden.
Zum WARUM und zum WIE.


Implementing fault-tolerant services using the state machine approach (1990)
https://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf
Das ist so die erste Abhandlung zum "WARUM"


Automata-Based Software Reliability Model: The Key to Reliable Software
http://www.sersc.org/journals/IJSEIA/vol7_no6_2013/10.pdf
Hier ist ein bisschen zum "WIE", interessant sind aber vor allem Kapitel 6, Kapitel 7.
Interessant ist hier, dass gezeigt wird, dass State Machines z.B. in Storage Arrays für konstantes, adaptives Tuning genutzt werden.
Das ist auch das, was unsere Systeme tun (können, sollen)


FINITE STATE MACHINES (2007)
http://web-ext.u-aizu.ac.jp/~hamada/AF/L2-FA07.pdf


Formale Sprachen (2013)
 Endliche Automaten, Grammatiken, lexikalische  und syntaktische Analyse;
 Hans-Joachim Böckenhauer, Juraj Hromkovic;
 Springer Vieweg; Wiesbaden 2013


#######
TOOLS
######

Finite State Machine Design Tools:

http://madebyevan.com/fsm/ (Web)
http://www.fizzim.com/ (Java)
https://www.itemis.com/en/yakindu/state-machine/ (Eclipse, non-free)

Ein bisschen weiter geht DRAKON:
http://drakon-editor.sourceforge.net/ (Was die Russische Raumfahrtagentur benutzt.
Mit Code Generator für manche Sprachen (C#, ERLANG). Genereller Support von Go, Java, C#, Python, ERLANG, ...)
WebVersion: https://drakon-editor.com


############
FAULT TREES
############


Fault Trees werden genutzt, um aufzuzeigen, wodurch einzelne Komponenten in einem System ausfallen können.
Oft gibt es ja mehrere Gründe, die das gleiche (oftmals schlechte) Ergebniss erzeugen können.
Oft gibt es auch mehrere Dinge, welche dies hätten verhindern können.
Dies abzubilden ist die Fault Tree Analyse (FTA) und erfolgt entweder für größere Systemkomponenten oder Einzelteile.
In einem Fault Tree kann man dies visuell darstellen und die Wahrscheinlichkeiten in Verhältnis setzen.
Hierdurch ist es dann auch möglich, einzelne Fehler einzurechnen, bei denen nicht so klar ist, wie leicht sie auftreten.
Das nennt sich Dynamic Fault Tree Analysis (DFTA), und wenn man bereits Fault Trees benutzt, nur eine Erweiterung.

Wichtiger ist aber ist:
In ALLEN Branchen, in denen hochsichere Software benutzt wird, wird seit Jahrzehnten erfolgreich mit FTA gearbeitet.
Für kritische Komponenten können wir ebenfalls so arbeiten, oder uns daran anlehnen.


###########################################################
Buchreferenzen und Historie von Fehleranalyse / Fault Trees
###########################################################


"Offiziell" wird die in einer zu befolgenden Anleitung festgehalten
Fault Tree Handbook (1981)
https://www.nrc.gov/docs/ML1007/ML100780465.pdf
Bereits vorher eingesetzt, aber hier werden die Standards und Anwendung erklärt.
Es ist zwar generalistisch aber alle Beispiele kommen aus der Nuklear-Techink.
Geht für uns zu tief rein, wir sind ja erst am Anfang.


Ein altes deutschsprachiges Buch das auch Pflichtlektüre werden sollte,
weil es sich mit den wahrscheinlichkeiten von Fehlerklassen befasst, ist;
Denkfallen und Programmierfehler (1990)
Wenige Seiten, aber viel zum Nachdenken.


Die erste gut durchschaubare Ausarbeitung fuer "Sysadmin und General IT" ist
A Probabilistic Approach to Estimating Computer System Reliability (2002)
https://www.usenix.org/legacy/events/lisa2001/tech/apthorpe/apthorpe.pdf
Diese sollte man _unbedingt_ lesen (auch mehrmals).
Es werden wichtige Grundmethoden erklärt, wie z.B. das identifizeren von fehlerrelevanten Komponenten.
Am wichtigsten ist es, die Grundprinzipien und Analysetechniken zu lernen.
Ob man jede Formel durchschaut ist nicht das wichtige Kriterium.
Falls man tief reinwill: Google: DFTA, Markov-Ketten, CORAL und unten siehe Tools.


Ein Buch, das sich vor allem mit dem Auswerten und Gegensteuern von Fehlern sowie Netzwerkeffekten sowie Netzerkeffekten von Fehlern befasst:
Analytical Network and System Administation (2003)


Eine aktuellere, für's Softwaredesign relevantere Dokumentation gibt es von der NASA:
NASA Fault Tree Handbook
https://elibrary.gsfc.nasa.gov/_assets/doclibBidder/tech_docs/25.%20NASA_Fault_Tree_Handbook_with_Aerospace_Applications%20-%20Copy.pdf
Hier werden Fault Trees für das Systemdesign erklärt - also nicht nur SW-Development sondern komplette Systeme.
Ganz grob ist das (neben ihren anderen Codingstandards) die Erklärung, warum in der Raumfahrt trotz wesentlich weniger Einsätzen und wesentlich komplexerer Systeme meist alles funktioniert.
Hohe Codingstandards sorgen für robuste Software, und die Berechnung / Überwachung von Ausfallwahrscheinlichkeiten macht es möglich, mit den Risiken sicher umzugehen.
(Siehe auch unten IS AGILE TOO FRAGILE FOR SPACEBASED SYSTEMS ENGINEERING?)

Mission-Critical and Safety-Critical Systems Handbook: Design and Development for Embedded Applications (2009)
https://www.amazon.de/Mission-Critical-Safety-Critical-Systems-Handbook-Applications/dp/0750685670
Checklisten und Erfahrungsberichte von Entwicklern aus sicherheitsrelevanten Projekten (Automobil, Luft- & Raumfahrt, Industrie, Militär, ...)


###############
Praesentationen
###############

# Safety Critical Systems Design
# Patterns and Practices for Designing Mission and Safety Critical Systems
http://omg.net/news/meetings/workshops/RT_2002_Workshop_Presentations/01-3_Douglass_Safety_Critical_Systems_Design.pdf
Eine extrem gute Übersicht über sicheres Systemdesign, wo Entwicklungsprozesse angepasst werden müssen, welche Verfahren sich bewährt haben.
Das kommt in dem Fall von einer "normalen" SW-Firma, bis zu einem gewissen Masse kann man also alles zumindest abgeschwächt verwenden.


# IS AGILE TOO FRAGILE FOR SPACEBASED SYSTEMS ENGINEERING?
http://www4.ncsu.edu/~scarpen/Research_files/Agile_Too_Fragile_scarpenter2013.pdf
Sehr neutral wird dargestellt, wie flexiblere Entwicklung in kritischen Umfeldern funktionieren kann (nur passende Teile umsetzen), und wie es auch scheitern kann, wenn es einfach verordnet wird.
Lehrreich weil die Präesentation recht neu ist und viele Praxisdetails mitbringt


###########
Generelles
###########


#######
TOOLS
#######
https://github.com/cmu-sei/emfta
This is an EMF-based FTA editor/visualizer. You can edit the content in our FTA within Eclipse using a convenient representation (table) and visualize a graphical (diagram) version.

https://github.com/rakhimov/scram
SCRAM is a Command-line Risk Analysis Multi-tool.
This project aims to build a command line tool for probabilistic risk analysis. SCRAM is capable of performing event tree analysis, static fault tree analysis, analysis with common cause failure models, probability calculations with importance analysis, and uncertainty analysis with Monte Carlo simulations. This tool can handle non-coherent fault trees, containing NOT logic.

The Deadlock Empire
https://deadlockempire.github.io/
Slay dragons, master concurrency!


################
Coding Standards
################

# CMMI for Development (2010)
https://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15287.pdf
Extrem komplex und tiefgehend, nicht vollanwendbar, bitte nicht komplett lesen...
ABER die Kapitel zu Risk Management und Tests sind OK!

NASA System Engineering Handbook (1995-2017...)
https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170001761.pdf
weitere links sind da auch drin.
https://www.nasa.gov/feature/release-of-revision-to-the-nasa-systems-engineering-handbook-sp-2016-6105-rev-2
(Sinnvoll sind die Kapitel: 4, teilweise 5 und besonders 6.3, 6.4 plus die Anhaenge)

###########
Testing
###########

Software Testing for Sysadmin Programs (2015)
http://menlo.com/tdd4sa/login_apr15_06_moskowitz.pdf


Vorschlaege von mir - Tests die die Verarbeitung betreffen (z.b. Daten aus einer API, Daten aus einem Kommandooutput)
Testen mit allen externen Kommandos auf /bin/true, dann auf /bin/false
Testen mit fake Daten (echo „QUERYERGEBNIS“ anstatte SQL Query)
Testen mit fehlerhaften Daten
Testen mit - denkt drueber nach - leeren Daten


An Empirical Study on Configuration Errors in Commercial and Open Source Systems (2011)
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.220.6745&rep=rep1&type=pdf
(lesen: warum config / option parser extrem wichtig sind)

Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems (2014)
https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf
(lesen: was ist gutes error handling, und was sind die folgen von unzureichendem error handling)

Proactive Detection of Inadequate Diagnostic Messages for Software Configuration Errors
https://homes.cs.washington.edu/~mernst/pubs/inadequate-diagnostics-issta2015.pdf

Debugging Designs (The 2011 presentation used to introduce system testing at Amazon!)
http://hpts.ws/papers/2011/sessions_2011/Debugging.pdf


Use of Formal Methods at Amazon Web Services (the results thereof)
http://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf

Design and Validation of Cloud Computing Data Stores using Formal Methods
http://assured-cloud-computing.illinois.edu/files/2014/03/Design-and-Validation-of-Cloud-Computing-Data-Stores-using-Formal-Methods.pdf

2-Stunden Kurs zu TLA+
https://www.youtube.com/playlist?list=PLFPjnNcHYXT1uazqO130o8oYmrpKsB5L7

Ron Pressler - The Practice and Theory of TLA+
https://www.youtube.com/watch?v=15uy9Ga-14I


#####
Doku
#####

Doxygen Tutorial:
https://www.cypax.net/tutorials/doxygen/

Doxygen Quick Reference:
http://www.digilife.be/quickreferences/QRC/Doxygen%20Quick%20Reference.pdf

Doxygen fuer Shellscripts
http://rickfoosusa.blogspot.de/2011/08/howto-have-doxygen-support-bash-script.html

Bash-doxygen
https://github.com/Anvil/bash-doxygen


Intel DPDK Doku zur Nutzung von Doxygen
http://dpdk.org/doc/guides/contributing/documentation.html

CFEngine Doku Standard (für doxygen)
https://github.com/cfengine/documentation

(Der Thread: https://groups.google.com/forum/#!topic/help-cfengine/_0urLa5EyDo)
POD:
NW> With some trickery you can add inline docs using the @if marco in 3.7:
NW> @if minimum_version(9.9)
NW> =pod

POD fuer Shellscrips
http://bahut.alma.ch/2007/08/embedding-documentation-in-shell-script_16.html

Sphinx:
https://pypi.python.org/pypi/sphinxcontrib-cf3domain
http://cf-propane.readthedocs.io/en/latest/
Anmerkung: Ich rate ganz klar nur zu doxygen!!!
#######
Option Parser
#####

docopt ist der einzig sinnvolle, durchdachte, bugarme parser, der heute noch Sinn macht.
POSIX-konformes Help-format erzeugt automatisch den Rest.

intro:
https://www.youtube.com/watch?v=pXhcPJK5cMc

docopt
https://github.com/docopt/docopt

docopt (perl)
https://github.com/tokuhirom/Docopt

docopt Shell (nutzt python)
https://github.com/docopt/docopts


############
Shell Coding
############

# Google Shell styleguide
https://google.github.io/styleguide/shell.xml
# Defensive Shell Programming
http://www.kfirlavi.com/blog/2012/11/14/defensive-bash-programming
# Bash Style Guide
https://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf
# Writing robust shell scripts
http://www.davidpashley.com/articles/writing-robust-shell-scripts/#id2596016
# Bash error handling
http://fvue.nl/wiki/Bash:_Error_handling
# Beautiful Bash (2014)
https://www.slideshare.net/a_z_e_t/inpresentation
# Deklarative Bash Funktionen
https://github.com/threatgrid/declarative.bash
Eine Library welche sich zum "automatischen" Schreiben von robusterem Code nutzen lässt.

# bats
https://github.com/sstephenson/bats
Eine recht leistungsfaehige Testlibrary fuer Shell - nutzen, wenn komplexere Tests oder Anlehnung an erweiterte Frameworks gewollt ist.
https://github.com/ztombol/bats-assert
Erweiterung, um Assertions zu hinterlegen (!!!)

# BATS und autoformatting intro
https://oscarforner.com/2018/02/24/Software_development_using_Bash

# Gute Funktionsdoku
https://svn.sdsc.edu/repo/scigap/tags/portal-R32.15/sdk/scripts/remote_resource/trestles/PBterminator.bash
Welche aber auch ein paar Bugs hat ;-)


# Coverage Tests
# kcov
http://simonkagstrom.github.io/kcov/
http://simonkagstrom.livejournal.com/50380.html (Hintergrund)

# bashcov
https://github.com/infertux/bashcov

# Shellcheck.net fuer automatische Schoenheitschecks und gegen haeufige Fehler
https://github.com/koalaman/shellcheck
# Es gibt einige Gitlab-CI Anbindungen fuer Shellcheck, aber scheinbar keine Best Practice.


Hilfreichste Infos aus diesen Script-Guidelines:

* Gute Doku
* set -u
* Postconditions am Funktionsende (Validierung, dass eine sinnvolle Operation stattfand)
* Preconditions (Eingangsdaten entsprechen Format? Wertebereiche? Parameter wie erwartet?)
* Funktionen mit negativem Default: return 1 ist der Standard, außer es hat Funktioniert
	##############
	State Machines
	##############


	Finite State Machines und davon abgeleitetes Anwendungsdesign sind das, was viele Industrie-Systeme robust macht.
	Jede TCP Connection, jede SMTP Übertragung durchläuft eine protokollseitige State Machine.
	In Software findet man sie als Grundlage vieler moderner Anwendungen im Cloud-Bereich.
	CFEngine ist darauf aufgebaut, ebenso kommerzielle Cluster wie VCS (alle Monitor Agents von VCS sind State Machines).

	Finite State Machines dienen als Abstraktionsebene, diese ermöglicht IMMER einen definierten Zustand zu erreichen.


	##############################################
	Buchreferenzen und Historie von State Machines
	##############################################


	Grundsätzlich behandelt jedes Buch zu Algorithmen / Informatik wohl auch State Machines.
	Schwieriger ist es, praxistaugliche Erläuterungen zu finden.
	Zum WARUM und zum WIE.


	Implementing fault-tolerant services using the state machine approach (1990)
	https://www.cs.cornell.edu/fbs/publications/SMSurvey.pdf
	Das ist so die erste Abhandlung zum "WARUM"


	Automata-Based Software Reliability Model: The Key to Reliable Software
	http://www.sersc.org/journals/IJSEIA/vol7_no6_2013/10.pdf
	Hier ist ein bisschen zum "WIE", interessant sind aber vor allem Kapitel 6, Kapitel 7.
	Interessant ist hier, dass gezeigt wird, dass State Machines z.B. in Storage Arrays für konstantes, adaptives Tuning genutzt werden.
	Das ist auch das, was unsere Systeme tun (können, sollen)


	FINITE STATE MACHINES (2007)
	http://web-ext.u-aizu.ac.jp/~hamada/AF/L2-FA07.pdf


	Formale Sprachen (2013)
	Endliche Automaten, Grammatiken, lexikalische und syntaktische Analyse;
	Hans-Joachim Böckenhauer, Juraj Hromkovic;
	Springer Vieweg; Wiesbaden 2013


	#######
	TOOLS
	######

	Finite State Machine Design Tools:

	http://madebyevan.com/fsm/ (Web)
	http://www.fizzim.com/ (Java)
	https://www.itemis.com/en/yakindu/state-machine/ (Eclipse, non-free)

	Ein bisschen weiter geht DRAKON:
	http://drakon-editor.sourceforge.net/ (Was die Russische Raumfahrtagentur benutzt.
	Mit Code Generator für manche Sprachen (C#, ERLANG). Genereller Support von Go, Java, C#, Python, ERLANG, ...)
	WebVersion: https://drakon-editor.com


	############
	FAULT TREES
	############


	Fault Trees werden genutzt, um aufzuzeigen, wodurch einzelne Komponenten in einem System ausfallen können.
	Oft gibt es ja mehrere Gründe, die das gleiche (oftmals schlechte) Ergebniss erzeugen können.
	Oft gibt es auch mehrere Dinge, welche dies hätten verhindern können.
	Dies abzubilden ist die Fault Tree Analyse (FTA) und erfolgt entweder für größere Systemkomponenten oder Einzelteile.
	In einem Fault Tree kann man dies visuell darstellen und die Wahrscheinlichkeiten in Verhältnis setzen.
	Hierdurch ist es dann auch möglich, einzelne Fehler einzurechnen, bei denen nicht so klar ist, wie leicht sie auftreten.
	Das nennt sich Dynamic Fault Tree Analysis (DFTA), und wenn man bereits Fault Trees benutzt, nur eine Erweiterung.

	Wichtiger ist aber ist:
	In ALLEN Branchen, in denen hochsichere Software benutzt wird, wird seit Jahrzehnten erfolgreich mit FTA gearbeitet.
	Für kritische Komponenten können wir ebenfalls so arbeiten, oder uns daran anlehnen.


	###########################################################
	Buchreferenzen und Historie von Fehleranalyse / Fault Trees
	###########################################################



	"Offiziell" wird die in einer zu befolgenden Anleitung festgehalten
	Fault Tree Handbook (1981)
	https://www.nrc.gov/docs/ML1007/ML100780465.pdf
	Bereits vorher eingesetzt, aber hier werden die Standards und Anwendung erklärt.
	Es ist zwar generalistisch aber alle Beispiele kommen aus der Nuklear-Techink.
	Geht für uns zu tief rein, wir sind ja erst am Anfang.


	Ein altes deutschsprachiges Buch das auch Pflichtlektüre werden sollte,
	weil es sich mit den wahrscheinlichkeiten von Fehlerklassen befasst, ist;
	Denkfallen und Programmierfehler (1990)
	Wenige Seiten, aber viel zum Nachdenken.


	Die erste gut durchschaubare Ausarbeitung fuer "Sysadmin und General IT" ist
	A Probabilistic Approach to Estimating Computer System Reliability (2002)
	https://www.usenix.org/legacy/events/lisa2001/tech/apthorpe/apthorpe.pdf
	Diese sollte man _unbedingt_ lesen (auch mehrmals).
	Es werden wichtige Grundmethoden erklärt, wie z.B. das identifizeren von fehlerrelevanten Komponenten.
	Am wichtigsten ist es, die Grundprinzipien und Analysetechniken zu lernen.
	Ob man jede Formel durchschaut ist nicht das wichtige Kriterium.
	Falls man tief reinwill: Google: DFTA, Markov-Ketten, CORAL und unten siehe Tools.


	Ein Buch, das sich vor allem mit dem Auswerten und Gegensteuern von Fehlern sowie Netzwerkeffekten sowie Netzerkeffekten von Fehlern befasst:
	Analytical Network and System Administation (2003)


	Eine aktuellere, für's Softwaredesign relevantere Dokumentation gibt es von der NASA:
	NASA Fault Tree Handbook
	https://elibrary.gsfc.nasa.gov/_assets/doclibBidder/tech_docs/25.%20NASA_Fault_Tree_Handbook_with_Aerospace_Applications%20-%20Copy.pdf
	Hier werden Fault Trees für das Systemdesign erklärt - also nicht nur SW-Development sondern komplette Systeme.
	Ganz grob ist das (neben ihren anderen Codingstandards) die Erklärung, warum in der Raumfahrt trotz wesentlich weniger Einsätzen und wesentlich komplexerer Systeme meist alles funktioniert.
	Hohe Codingstandards sorgen für robuste Software, und die Berechnung / Überwachung von Ausfallwahrscheinlichkeiten macht es möglich, mit den Risiken sicher umzugehen.
	(Siehe auch unten IS AGILE TOO FRAGILE FOR SPACEBASED SYSTEMS ENGINEERING?)

	Mission-Critical and Safety-Critical Systems Handbook: Design and Development for Embedded Applications (2009)
	https://www.amazon.de/Mission-Critical-Safety-Critical-Systems-Handbook-Applications/dp/0750685670
	Checklisten und Erfahrungsberichte von Entwicklern aus sicherheitsrelevanten Projekten (Automobil, Luft- & Raumfahrt, Industrie, Militär, ...)


	###############
	Praesentationen
	###############

	# Safety Critical Systems Design
	# Patterns and Practices for Designing Mission and Safety Critical Systems
	http://omg.net/news/meetings/workshops/RT_2002_Workshop_Presentations/01-3_Douglass_Safety_Critical_Systems_Design.pdf
	Eine extrem gute Übersicht über sicheres Systemdesign, wo Entwicklungsprozesse angepasst werden müssen, welche Verfahren sich bewährt haben.
	Das kommt in dem Fall von einer "normalen" SW-Firma, bis zu einem gewissen Masse kann man also alles zumindest abgeschwächt verwenden.


	# IS AGILE TOO FRAGILE FOR SPACEBASED SYSTEMS ENGINEERING?
	http://www4.ncsu.edu/~scarpen/Research_files/Agile_Too_Fragile_scarpenter2013.pdf
	Sehr neutral wird dargestellt, wie flexiblere Entwicklung in kritischen Umfeldern funktionieren kann (nur passende Teile umsetzen), und wie es auch scheitern kann, wenn es einfach verordnet wird.
	Lehrreich weil die Präesentation recht neu ist und viele Praxisdetails mitbringt



	###########
	Generelles
	###########


	#######
	TOOLS
	#######
	https://github.com/cmu-sei/emfta
	This is an EMF-based FTA editor/visualizer. You can edit the content in our FTA within Eclipse using a convenient representation (table) and visualize a graphical (diagram) version.

	https://github.com/rakhimov/scram
	SCRAM is a Command-line Risk Analysis Multi-tool.
	This project aims to build a command line tool for probabilistic risk analysis. SCRAM is capable of performing event tree analysis, static fault tree analysis, analysis with common cause failure models, probability calculations with importance analysis, and uncertainty analysis with Monte Carlo simulations. This tool can handle non-coherent fault trees, containing NOT logic.

	The Deadlock Empire
	https://deadlockempire.github.io/
	Slay dragons, master concurrency!




	################
	Coding Standards
	################

	# CMMI for Development (2010)
	https://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15287.pdf
	Extrem komplex und tiefgehend, nicht vollanwendbar, bitte nicht komplett lesen...
	ABER die Kapitel zu Risk Management und Tests sind OK!

	NASA System Engineering Handbook (1995-2017...)
	https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20170001761.pdf
	weitere links sind da auch drin.
	https://www.nasa.gov/feature/release-of-revision-to-the-nasa-systems-engineering-handbook-sp-2016-6105-rev-2
	(Sinnvoll sind die Kapitel: 4, teilweise 5 und besonders 6.3, 6.4 plus die Anhaenge)

	###########
	Testing
	###########

	Software Testing for Sysadmin Programs (2015)
	http://menlo.com/tdd4sa/login_apr15_06_moskowitz.pdf


	Vorschlaege von mir - Tests die die Verarbeitung betreffen (z.b. Daten aus einer API, Daten aus einem Kommandooutput)
	Testen mit allen externen Kommandos auf /bin/true, dann auf /bin/false
	Testen mit fake Daten (echo „QUERYERGEBNIS“ anstatte SQL Query)
	Testen mit fehlerhaften Daten
	Testen mit - denkt drueber nach - leeren Daten


	An Empirical Study on Configuration Errors in Commercial and Open Source Systems (2011)
	http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.220.6745&rep=rep1&type=pdf
	(lesen: warum config / option parser extrem wichtig sind)

	Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems (2014)
	https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf
	(lesen: was ist gutes error handling, und was sind die folgen von unzureichendem error handling)

	Proactive Detection of Inadequate Diagnostic Messages for Software Configuration Errors
	https://homes.cs.washington.edu/~mernst/pubs/inadequate-diagnostics-issta2015.pdf

	Debugging Designs (The 2011 presentation used to introduce system testing at Amazon!)
	http://hpts.ws/papers/2011/sessions_2011/Debugging.pdf


	Use of Formal Methods at Amazon Web Services (the results thereof)
	http://lamport.azurewebsites.net/tla/formal-methods-amazon.pdf

	Design and Validation of Cloud Computing Data Stores using Formal Methods
	http://assured-cloud-computing.illinois.edu/files/2014/03/Design-and-Validation-of-Cloud-Computing-Data-Stores-using-Formal-Methods.pdf

	2-Stunden Kurs zu TLA+
	https://www.youtube.com/playlist?list=PLFPjnNcHYXT1uazqO130o8oYmrpKsB5L7

	Ron Pressler - The Practice and Theory of TLA+
	https://www.youtube.com/watch?v=15uy9Ga-14I



	#####
	Doku
	#####

	Doxygen Tutorial:
	https://www.cypax.net/tutorials/doxygen/

	Doxygen Quick Reference:
	http://www.digilife.be/quickreferences/QRC/Doxygen%20Quick%20Reference.pdf

	Doxygen fuer Shellscripts
	http://rickfoosusa.blogspot.de/2011/08/howto-have-doxygen-support-bash-script.html

	Bash-doxygen
	https://github.com/Anvil/bash-doxygen


	Intel DPDK Doku zur Nutzung von Doxygen
	http://dpdk.org/doc/guides/contributing/documentation.html

	CFEngine Doku Standard (für doxygen)
	https://github.com/cfengine/documentation

	(Der Thread: https://groups.google.com/forum/#!topic/help-cfengine/_0urLa5EyDo)
	POD:
	NW> With some trickery you can add inline docs using the @if marco in 3.7:
	NW> @if minimum_version(9.9)
	NW> =pod

	POD fuer Shellscrips
	http://bahut.alma.ch/2007/08/embedding-documentation-in-shell-script_16.html

	Sphinx:
	https://pypi.python.org/pypi/sphinxcontrib-cf3domain
	http://cf-propane.readthedocs.io/en/latest/
	Anmerkung: Ich rate ganz klar nur zu doxygen!!!
	#######
	Option Parser
	#####

	docopt ist der einzig sinnvolle, durchdachte, bugarme parser, der heute noch Sinn macht.
	POSIX-konformes Help-format erzeugt automatisch den Rest.

	intro:
	https://www.youtube.com/watch?v=pXhcPJK5cMc

	docopt
	https://github.com/docopt/docopt

	docopt (perl)
	https://github.com/tokuhirom/Docopt

	docopt Shell (nutzt python)
	https://github.com/docopt/docopts



	############
	Shell Coding
	############

	# Google Shell styleguide
	https://google.github.io/styleguide/shell.xml
	# Defensive Shell Programming
	http://www.kfirlavi.com/blog/2012/11/14/defensive-bash-programming
	# Bash Style Guide
	https://lug.fh-swf.de/vim/vim-bash/StyleGuideShell.en.pdf
	# Writing robust shell scripts
	http://www.davidpashley.com/articles/writing-robust-shell-scripts/#id2596016
	# Bash error handling
	http://fvue.nl/wiki/Bash:_Error_handling
	# Beautiful Bash (2014)
	https://www.slideshare.net/a_z_e_t/inpresentation
	# Deklarative Bash Funktionen
	https://github.com/threatgrid/declarative.bash
	Eine Library welche sich zum "automatischen" Schreiben von robusterem Code nutzen lässt.

	# bats
	https://github.com/sstephenson/bats
	Eine recht leistungsfaehige Testlibrary fuer Shell - nutzen, wenn komplexere Tests oder Anlehnung an erweiterte Frameworks gewollt ist.
	https://github.com/ztombol/bats-assert
	Erweiterung, um Assertions zu hinterlegen (!!!)

	# BATS und autoformatting intro
	https://oscarforner.com/2018/02/24/Software_development_using_Bash

	# Gute Funktionsdoku
	https://svn.sdsc.edu/repo/scigap/tags/portal-R32.15/sdk/scripts/remote_resource/trestles/PBterminator.bash
	Welche aber auch ein paar Bugs hat ;-)


	# Coverage Tests
	# kcov
	http://simonkagstrom.github.io/kcov/
	http://simonkagstrom.livejournal.com/50380.html (Hintergrund)

	# bashcov
	https://github.com/infertux/bashcov

	# Shellcheck.net fuer automatische Schoenheitschecks und gegen haeufige Fehler
	https://github.com/koalaman/shellcheck
	# Es gibt einige Gitlab-CI Anbindungen fuer Shellcheck, aber scheinbar keine Best Practice.



	Hilfreichste Infos aus diesen Script-Guidelines:

	* Gute Doku
	* set -u
	* Postconditions am Funktionsende (Validierung, dass eine sinnvolle Operation stattfand)
	* Preconditions (Eingangsdaten entsprechen Format? Wertebereiche? Parameter wie erwartet?)
	* Funktionen mit negativem Default: return 1 ist der Standard, außer es hat Funktioniert