[0:00] Herzlich willkommen zum IT-Berufe-Podcast, dem Podcast rund um die Ausbildung in den

[0:07] IT-Berufen. In dieser Episode geht es um Plain-Text-Markup-Formate zum Schreiben

[0:13] längerer Texte. Viel Spaß! Hallo und herzlich willkommen zur 155. Episode des IT-Berufe-Podcasts.

[0:26] Mein Name ist Stefan Macke und heute geht es mal nicht um etwas Prüfungsrelevantes, sondern eher

[0:31] um etwas Praxisrelevantes. Auch das ist ja so ein bisschen mein Ansatz, dass ich eben was erzähle,

[0:36] was du auch in deinem Alltag einsetzen kannst und was dir vielleicht das Leben ein bisschen

[0:40] einfacher macht. Also, heute habe ich ein schönes Thema mitgebracht und zwar Plain-Text-Markup-Formate

[0:45] habe ich es mal genannt. Was heißt das, worum soll es hier gehen? Ich möchte dir gerne ein paar

[0:50] Formate vorstellen, die du in reinen Textdateien nutzen kannst, um zum Beispiel längere Texte zu

[0:55] schreiben, eventuell sogar irgendwann einmal deine Projektdokumentation für die Abschlussprüfung.

[0:59] Wer weiß. Aber es geht auch um viele andere Use Cases, wie zum Beispiel Dokumentation von

[1:04] Software oder meinetwegen auch E-Mail-Vorlagen oder, ich weiß es nicht, Blog-Artikel. Alles

[1:10] Mögliche kannst du mit diesen Textformaten schreiben und du brauchst dafür kein besonderes

[1:14] Programm, sondern kannst eben reine Textdateien benutzen. Das ist da der große Vorteil. Eines

[1:19] dieser Formate kennst du bestimmt schon und zwar HTML, die Hypertext Markup Language. Das ist

[1:24] letztlich auch nichts anderes als ein Plain-Text-Format für Markup, also eine Auszeichnungssprache. Jetzt

[1:30] würde ich nicht auf die Idee kommen, dir zu empfehlen, deine Texte in HTML zu schreiben. Das

[1:33] ist nämlich mega aufwendig und genau darum geht es jetzt bei den Sprachen, die ich heute vorstelle.

[1:37] Ich möchte das nicht so aufwendig haben, also öffnender Tag, schließender Tag, korrekte

[1:41] Syntax, Klammer auf, etc. Das will ich nicht, sondern ich will meinen Text eigentlich runterschreiben

[1:46] können in einem einfach zu verstehenden Format, wo ich nicht noch irgendwie fünf Wochen Schulung

[1:51] brauche oder irgendwas. Und das Ganze soll dann halt in reinen Textdateien abgelegt werden,

[1:55] sodass ich die ganzen Vorzüge von Textformaten nutzen kann. Und bevor wir uns diese Vorteile

[2:00] einmal anschauen, nenne ich dir vielleicht mal ein paar konkrete Formate, die ich so im Alltag

[2:04] benutze und die ich heute vielleicht auch ein Beispiel durchgehen will. Nummer 1, Markdown. Das

[2:08] ist das zentrale Format, mit dem man heutzutage fast alles machen kann und das sehr oft und sehr

[2:13] breit unterstützt wird. Dann gibt es noch ASCIDoc, wenn du richtig was aufschreiben musst mit Fußnoten

[2:19] und ich weiß nicht was, gehen wir später noch drauf ein. Dann gibt es Textile, ist eine Syntax,

[2:24] die zum Beispiel im Projektmanagement-Tool Redmine verwendet wird, da benutze ich die zum Beispiel

[2:29] täglich. Natürlich LaTeX, da habe ich schon öfter hier im Podcast was darüber berichtet,

[2:33] meine Vorlage für die Projektdokumentation ist ja auch in LaTeX entwickelt. Und zum Schluss habe

[2:38] ich noch ein kleines Unterformat in Anführungszeichen, nämlich PlantUML. Wir als Attiler

[2:42] müssen häufiger ja auch UML-Diagramme zeichnen und das kann man auch in Textform machen. Das heißt,

[2:47] du beschreibst einfach deine UML-Diagramme und die werden automatisch für dich zu Grafiken

[2:51] erstellt aus diesem Text, den du da eingegeben hast. Also diese Formate möchte ich heute kurz

[2:57] einmal durchgehen. Markdown, ASCIDoc, Textile, LaTeX und PlantUML. Doch bevor wir damit anfangen,

[3:04] einmal kurz einen Überblick der Vorteile dieser Plaintext-Formate. Und wie ich auf das Thema

[3:09] gekommen bin, ist der Buchclub, den ich gerade mit meinen Azubis mache, über das Buch Pragmatic

[3:14] Programmer. Also wirklich The Pragmatic Programmer, das Original, das 20 Jahre alte von Dave Thomas

[3:20] und Andy Hunt. Und das ist jetzt gerade vor kurzem in einer Neuauflage der 20th Anniversary Edition

[3:25] erschienen. Und da haben die noch mal ein bisschen was aktualisiert und coole neue Sachen eingebaut.

[3:29] Das lese ich gerade also noch mal neu mit meinen Azubis. Und ein Kapitel, was es aber schon in

[3:33] der ersten Version des Buches gab, geht rund um das Thema Plaintext. Und dort wird auch schön

[3:39] beschrieben, was die Vorteile sind. Und als ich das damals in meiner eigenen Ausbildung gelesen

[3:43] habe, da habe ich gesehen, Mensch, das ist richtig. Das stimmt, was die sagen. Und seitdem mache

[3:49] ich eigentlich alles im Plaintext, was ich im Plaintext machen kann. Und da gucken wir uns vielleicht

[3:52] mal kurz die Vorteile an, damit du auch verstehst, was der Sinn dahinter ist. Und Nummer eins dieser

[3:58] Plaintext-Formate, warum wir gerade als ITler oder sogar, wenn ich noch spezifischer werde,

[4:03] als Entwickler das gut finden, damit zu arbeiten, ist die Versionierbarkeit. Du kennst sicherlich

[4:09] Versionsverwaltungssysteme wie Git, Subversion, meinetwegen auch den Team-Foundation-Server von

[4:14] Microsoft. Die großen Vorteile spielen diese Server nur dann aus, beziehungsweise nicht nur

[4:19] Server, sondern auch die Software, nur dann aus, wenn du Plaintext-Formate hast. Wir grenzen das

[4:25] vielleicht mal ganz kurz ab. Was ist denn überhaupt nicht Plaintext? Also nicht Plaintext ist alles,

[4:29] was zum Beispiel in einem binären Format vorliegt, wie zum Beispiel Microsoft Word, LibreOffice oder

[4:35] irgendwelche Dateien, die aus bestimmten Anwendungsprodukten herauskommen. Ich nehme mal

[4:40] eine Photoshop-Datei, diese PSD-Endung. Das ist irgendein Binärformat, was nur von diesem einen

[4:45] Programm gelesen werden kann. Man sagt auch gern ein proprietäres Format. Das meint nicht

[4:50] hundertprozentig das Gleiche. Das meint eher, dass ein Hersteller quasi den Hut auf hat und dieses

[4:55] Format unter seiner Hoheit hat und dann niemand anderes drankommt. Das ist eigentlich eher

[4:59] proprietär. Aber beides schmeißt man so gerne zusammen, denn die genannten Formate wie Markdown

[5:06] und Asciidog und so sind auch offen zugänglich. Das heißt, jeder kann die benutzen und weiterentwickeln.

[5:10] Aber Microsoft Word zum Beispiel hat historisch eben ein Binärformat geschrieben, was auch nur

[5:14] Word bearbeiten konnte. Inzwischen ist das nicht mehr ganz so. Die haben ihr Format standardisieren

[5:20] lassen. Das ist ja inzwischen ein XML-Format, was aus den Office-Produkten herauspurzelt und auch

[5:25] andere Programme können dieses Format lesen und schreiben. XML ist übrigens auch ein Plain-Text-Format.

[5:31] Das kannst du auch mal im Texteditor drin rum ändern. Das kann ein Mensch lesen und auch eine

[5:35] Maschine. Aber Office geht jetzt einen Schritt weiter und nimmt jetzt dieses XML und zippt das

[5:40] Ganze dann. Und dann hast du leider kein Plain-Text mehr, sondern eben ein Binärformat. Kannst du

[5:45] übrigens auch mal ausprobieren, wenn du so eine Microsoft-Word-Datei .docx irgendwo abspeicherst

[5:49] und die einfach mal umbenennst in .zip hinten, kannst du die mit dem ZIP-Programm einfach

[5:53] aufmachen, reingucken und da siehst du dann quasi die XML-Inhalte. Das ist eigentlich das Word-Format.

[5:59] Und weil das aber sehr viel Speicher verbraucht, ist halt drumherum das Ding in einen ZIP-Container

[6:04] gepackt, damit es etwas kleiner wird. Und wenn du diese Datei jetzt aufmachst, im Texteditor zum

[6:08] Beispiel, da wirst du gar nichts mehr erkennen können. Das ist ein Binärformat. Das ist also

[6:12] nichts menschenlesbares mehr, sondern da werden quasi die einzelnen Bytes benutzt, um irgendwelche

[6:17] Sachen darzustellen, die du als Mensch aber überhaupt nicht interpretieren kannst. Sobald

[6:21] du ein Byte änderst, kann es sein, dass die ganze Datei kaputt ist. Das heißt, diese Datei ist für

[6:24] dich nicht direkt änderbar. Du musst sie schon in einem Programm öffnen, das dafür vorgesehen ist,

[6:29] in unserem Beispiel Microsoft Word, und dann kannst du die Inhalte verändern. Aber die Datei selbst,

[6:34] die ist quasi unantastbar, denn da machst du mehr kaputt, als dass du irgendwie damit arbeiten

[6:38] kannst. So, und diese Formate haben den zentralen Nachteil. Nehmen wir mal das Beispiel Word. Du

[6:44] änderst ein Zeichen in der Word-Datei, speicherst die Datei, dann wird das irgendwo in der XML

[6:49] geändert, dieses Zeichen. Aber das Zip-Archiv drumherum wird ja komplett neu gebaut. Und jetzt

[6:53] kann es sein, dass das ganze Zip-Archiv auf einmal anders aussieht als vorher, einfach weil dieses

[6:57] Binärformat nicht den einen Buchstaben an der einen Stelle geändert hat, sondern diesen ganzen

[7:02] Zip-Container neu erstellt hat. Und auf einmal sieht das Ding komplett anders aus. Und da hast

[7:06] du den großen Vorteil der Versionierung, auf den ich hier gerade eingehen will, eben nicht mehr.

[7:10] Denn du hast einen Buchstaben geändert, aber, ich übertreibe jetzt mal, eine komplett andere

[7:15] riesengroße Datei ist daraus entstanden. Und wenn du jetzt deinem Versionierungstool sagst,

[7:19] hier, ich habe eine neue Version der Datei, dann sagt das Versionierungstool, Mensch, sehr cool,

[7:23] das ist ja eine komplett neue Datei. Das heißt, du kannst auch nichts vergleichen oder sowas,

[7:27] ja. Diese Binärformate ermöglichen dir also gerade die zentralen Vorteile einer

[7:31] Versionsverwaltungssoftware nicht. Nämlich diffen, das heißt Unterschiede zwischen Dateien

[7:37] anzeigen, mergen, das heißt mehrere gleichzeitig bearbeitete Versionen zu einer zusammenzuführen

[7:44] und zum Beispiel auch sowas wie Branches, das heißt mehrere Versionen eben parallel zu pflegen,

[7:48] zum Beispiel bei einer Dokumentation, wenn ein Mitarbeiter Kapitel 1 und der andere Kapitel 2

[7:52] bearbeitet, den wollt ihr am Ende zusammenführen. Das wird ganz schön schwierig mit den Binärformaten

[7:56] oder, um es nicht anders zu sagen, unmöglich, weil die Software das nicht anbieten kann. Bei

[8:02] Textformaten ist das anders. Wenn du eine Textdatei hast, einer arbeitet oben in der Datei, ein anderer

[8:06] irgendwo weiter unten, dann kann die Software, wie zum Beispiel GIT, das auf Knopfdruck zusammenführen.

[8:12] Denn es muss letztlich nichts anderes gemacht werden, als die beiden Dateien zusammen zu kopieren.

[8:16] Könntest du theoretisch auf der Kommandozeile auch machen, wenn du zum Beispiel ein cat-Befehl

[8:20] unter Linux benutzt, machst du cat Datei 1 und Datei 2 und rauskommt Datei 3, wo einfach

[8:25] beide anderen zusammen hintereinander konkateniert sind. Deswegen heißt der Befehl ja cat. Und das

[8:31] geht eben nur bei Plain-Textformaten, die halt nicht darauf angewiesen sind, dass sie quasi,

[8:36] ja wie soll man sagen, eine Art Einheit, ein ganzes Bilden wie bei einem Zip-File, wo wenn

[8:41] du ein einziges Bit änderst, dass ganze Dinge kaputt ist, auf deutsch gesagt. Und das ist ein

[8:44] großer Vorteil von Textdateien. Du kannst die so manipulieren, dass sie durch solche

[8:49] Versionsverwaltungssoftware gut verwaltet werden kann. Und das willst du haben. Du willst alles

[8:56] versioniert haben. Denk mal an eine Projektdokumentation. Angenommen, du schreibst die

[9:01] und du änderst da drin was, du machst eine Fehlerkorrektur, überarbeitest die Rechtschreibprüfung,

[9:05] was auch immer. Dann möchtest du sehen, was hast du geändert, wann hast du es geändert,

[9:10] möchtest das vielleicht sogar zurückrollen können auf einen alten Stand und so weiter.

[9:14] Alle diese Vorteile der Versionsverwaltung machst du dir kaputt, wenn du Binärformate benutzt. Ich

[9:18] sage nicht, dass du die nicht benutzen kannst. Du kannst zum Beispiel auch Bilder wie JPEG-Dateien

[9:22] oder so versionieren. Du kannst sie bloß nicht diffen, mergen und so weiter. Und das ist der

[9:27] zentrale Nachteil, weil dann hast du eigentlich nur die Möglichkeit zu sagen, so, neue Version,

[9:31] jetzt speichern. Aber du hast keine Möglichkeit, sie irgendwie mit den alten Versionen in Verbindung

[9:35] zu bringen, weil du eben nicht sinnvoll unterscheiden kannst, was da eigentlich geändert

[9:39] wurde zwischen diesen Versionen. Und damit machst du dir die ganze Versionierbarkeit eigentlich

[9:44] kaputt leider. So, ein weiterer Nachteil von diesen binären Formaten ist die fehlende

[9:52] Langlebigkeit. Wenn du dir mal wieder Word als Beispiel nimmst, die DOC-Dateien, die ich damals

[9:57] noch auf und runter benutzt habe, die sind heute eigentlich veraltet. Es gibt inzwischen ein neues

[10:00] Format, nämlich DOCX. Microsoft tut natürlich gut daran, die alten Formate auch weiterhin öffnen

[10:06] zu können. Das ist alles okay. Aber sobald Microsoft irgendwann mal sagt, ach komm, den alten

[10:09] Rotz, auf Deutsch gesagt, wollen wir nicht mehr unterstützen, dann stehst du da und kannst das

[10:14] Ding leider nicht mehr bearbeiten, weil der Editor, der das Ding erzeugt hat, das nicht mehr unterstützt.

[10:19] Und das ist natürlich schlecht. Du möchtest natürlich deine, was weiß ich, Texte, die du vor

[10:22] 20 Jahren geschrieben hast, auch heute noch öffnen können. Und das wird sehr schwierig, wenn du so

[10:26] ein Binärformat benutzt, das nur von einem ganz bestimmten Programm geöffnet werden kann. Denn wenn

[10:31] es dieses Programm aus irgendeinem Grund nicht mehr gibt, und das reicht ja schon, dass der

[10:34] Hersteller einfach sagt, nö, ich will das alte Zeug nicht mehr unterstützen, dann stehst du da und

[10:39] kannst das Ding nicht mehr öffnen. Oder du musst dir eine uralte Version von Word vorhalten, die

[10:42] aber vielleicht auf einer Windows-Version nicht mehr funktioniert und und und und. Also, du willst,

[10:46] dass deine Texte langlebig sind und das kriegst du hin mit Plain Text. Denn Plain Text-Dateien gibt

[10:52] es schon seit 50 Jahren, die wird es auch die nächsten 50 Jahre noch geben, einfach weil es ein

[10:55] Standard ist. Und du brauchst dafür keine besondere Software. Du kannst sie mit Konsolen-Befehlen

[11:00] unter Linux zum Beispiel einfach aufmachen. CAD oder du machst ein VI auf. Oder unter Windows kannst

[11:05] du den Notepad nehmen, um eine Textdatei zu öffnen. Das heißt, du brauchst nicht mal besondere

[11:10] Software. Du kannst jeden beliebigen Texteditor, und davon gibt es tausend verschiedene, einfach

[11:15] nutzen, um diese Datei zu lesen zum einen, aber auch zu bearbeiten. Das heißt, du kannst diese

[11:19] alte, diese alten Texte, die du geschrieben hast, auch in 20 Jahren noch öffnen und weiter pflegen

[11:24] quasi. Und das funktioniert wahrscheinlich nicht mit diesen Binär-Formaten, die vielleicht alle

[11:30] paar Jahre sich mal ändern oder irgendwann einfach nicht mehr unterstützt werden. Das heißt, du bist

[11:34] unabhängig von irgendwelchen Herstellern, die ihre Produkte pflegen, und du brauchst auch diese

[11:38] Software nicht mehr. Ich habe früher viele Sachen mit Photoshop gemacht. Inzwischen bin ich auf

[11:43] kostenfreie Software umgestiegen, wie zum Beispiel Paint.net, weil ich jetzt einfach nicht mehr so

[11:46] die heftigen Photoshop-Skills brauche, um irgendwas zu manipulieren. Aber ich habe noch ganz viele

[11:52] Photoshop-Dateien rumliegen. Die alte Version von Photoshop, die ich noch irgendwo mal lizenziert

[11:57] hatte, die funktioniert aber auf neueren Windows-Versionen gar nicht mehr. Und jetzt stehe ich

[12:00] da. Jetzt habe ich ganz viele tolle Photoshop-Dateien, kann sie aber leider nicht mehr aufmachen. Und das

[12:05] ist uncool. Deswegen, Plain Text wirst du auch in 20 Jahren noch öffnen können, und das ist ganz toll.

[12:11] Dann machst du deine Arbeit nur einmal und musst sie nicht in 20 Jahren noch mal neu machen, weil

[12:15] du die Dateien nicht mehr öffnen kannst. Nächster Punkt, Plain Text ist toll, weil wir produktiver

[12:20] arbeiten können. Denn du hast wirklich Plain Text, wie der Name sagt, also reine Textdateien. Da ist

[12:25] nichts zusätzlich drin, was du als Mensch nicht bearbeiten kannst oder einen Texteditor nicht

[12:29] bearbeiten kannst. Also insbesondere irgendwelche Steuerzeichen oder eben irgendwelche Bit- oder

[12:33] Bytecodes, die kein Mensch versteht, außer eine besondere Software. Und das heißt, du brauchst zur

[12:39] Bearbeitung auch wirklich nur einen Editor, einen Texteditor. Du brauchst nicht wie in Word vielleicht

[12:45] noch zusätzlich die Maus, um irgendwo ins Menü zu klicken und irgendwas auszuwählen, sondern du

[12:48] arbeitest direkt im Text. Das heißt, du kannst Kommandozeilen-Werkzeuge benutzen. Du kannst

[12:52] theoretisch mit Linux Textdateien auf der Kommandozeile pflegen, ohne überhaupt einen

[12:56] Editor aufzumachen. Und das sind natürlich riesengroße Vorteile bei der Produktivität,

[13:00] denn Tastatur ist immer schneller als die Maus. Gehen wir mal davon aus, dass du vernünftig tippen

[13:05] kannst und dir das Zehnfingersystem angeeignet hast oder zumindest auf dem Weg dahin bist. Dann

[13:10] wirst du immer schneller mit der Tastatur deine Eingaben tätigen können, als mit der Maus

[13:14] irgendwo hinzuklicken. Und das ist der große Vorteil. Wenn du Plaintext hast, musst du überhaupt

[13:18] gar nicht klicken, denn du musst ja einfach nur schreiben und vielleicht einen Editor benutzen,

[13:22] der dir die Navigation im Text etwas einfacher macht, mit möglichst wenig Tasten drücken,

[13:26] wie zum Beispiel der VI. Aber du brauchst auf keinen Fall eine Maus, um irgendwo deinen Text

[13:32] fett zu machen zum Beispiel. Viele Leute gehen ja hin in Word, markieren dann ein Wort mit der

[13:37] Maus und klicken dann oben auf Fett. Davon abgesehen, dass das grundsätzlich die völlig

[13:40] falsche Vorgehensweise ist, du Formatvorlagen benutzen musst und so weiter. Das lassen wir

[13:44] jetzt mal dahin gestellt. Aber diese Arbeit mit der Maus macht dich halt mega langsam, weil du

[13:48] immer switchen musst zwischen Tastatur und Maus. Und das wollen wir nicht. Deswegen Plaintext,

[13:53] wunderbar, reiner Texteditor. Ohne Maus kannst du da alles machen, was du machen willst. Und ich

[13:58] hatte es jetzt schon ein paar mal angesprochen, du kannst theoretisch jeden Editor benutzen,

[14:01] den es da draußen gibt, denn die können alle Textdateien bearbeiten. Das heißt, du hast einen

[14:05] weiteren großen Vorteil, nämlich die Flexibilität. Du bist nicht angewiesen auf ein Tool von einem

[14:10] Hersteller. Ich reite jetzt heute sehr stark auf Word rum. Ich nehme das mal wieder als Beispiel,

[14:14] weil viele das einfach kennen. Du wirst das bestimmt auch schon mal benutzt haben. Du kannst

[14:17] auch irgendein anderes kommerzielles Tool nehmen, das ist ganz egal. Aber Word, weil es so verbreitet

[14:21] ist, dient mir hier als Beispiel. Und wenn du zum Beispiel keinen Bock hast, mit Word zu arbeiten,

[14:25] weil dir das Tool nicht gefällt, du verstehst es nicht, du kannst es nicht, was auch immer,

[14:28] dann hast du leider Pech gehabt, denn Word ist nun mal das Tool, mit dem man Word-Dateien bearbeiten

[14:32] muss. Und wenn du Textdateien benutzt, ist das aber nicht dein Problem, denn du kannst einfach

[14:37] irgendeinen anderen Texteditor nehmen, wenn dir der, der vorgegeben ist, nicht gefällt. Textdateien

[14:41] kannst du, wie ich gerade schon gesagt habe, auf der Kommandozeile theoretisch mit Linux-Befehlen

[14:44] bearbeiten. Mit Windows geht das auch, aber nicht ganz so schön. Du kannst zur Not ein Notepad nehmen,

[14:48] der auf jedem Windows installiert ist, oder du nimmst halt einen vernünftigen Editor, sei es

[14:52] Emacs oder Vim oder Visual Studio Code zum Beispiel. Ist ganz egal. Du kannst dir dein Lieblingstool

[14:57] aussuchen und musst nicht ein Tool nehmen, was irgendwer dir vorgibt, nur weil das das Einzige ist,

[15:03] was das Format unterstützt. Und diese Flexibilität geht auch noch weiter. Und zwar kannst du, wenn

[15:08] das Format zum Beispiel in 20 Jahren nicht mehr so verbreitet ist, ich nehme jetzt mal Markdown

[15:12] als Beispiel, könntest du dir theoretisch sogar deinen eigenen Parser programmieren, der das

[15:17] Format wieder einliest und ausgibt und ich weiß nicht was. Denn diese Langlebigkeit der Textdateien

[15:22] trägt dazu bei, dass auch in Zukunft jede Programmiersprache irgendwie in der Lage sein

[15:26] wird, diese Dateien einzulesen. Und dann kannst du, voraussetzt das Format ist nicht allzu komplex,

[15:31] zur Not, wenn es keinen Parser mehr gibt, die einfach selber einen programmieren. Und wenn

[15:37] der Parser gefällt dir nicht oder die Darstellung sieht komisch aus, die der generiert oder sonst

[15:42] was, dann setzt du dich hin, baust dir deinen eigenen. Ich weiß, das führt jetzt ein bisschen

[15:45] weit, das werden wir wohl alle nicht machen. Also ich werde mir auch keinen eigenen Parser für irgendeinen

[15:48] Markup schreiben, aber du könntest es tun. Und das ist halt eben bei diesen Binärformaten

[15:56] deutlich schwieriger. Von daher, Flexibilität, großer Vorteil. Und letzter Punkt, Automatisierung.

[16:02] Diese Textdateien lassen sich perfekt automatisieren. Ich habe es gerade schon gesagt, jede

[16:06] Programmiersprache bietet irgendwas, um Textdateien einzulesen. Das ist ein Standard, eine Standard-

[16:10] Funktionalität von jedem Betriebssystem und jeder Sprache. Das heißt, wenn du auf Basis der Dateien

[16:14] irgendetwas automatisieren willst, dann kannst du das sofort machen, ohne externe Tools. Wenn

[16:19] du Word-Verarbeitung automatisieren willst, geht das zwar auch. Du könntest dir ein Word-Makro

[16:25] schreiben, in der fantastischen Programmiersprache VBA. Kannst du machen, funktioniert auch super.

[16:30] Funktioniert aber auch dann nur in Word. Das heißt, du brauchst immer Word, um irgendwas zu automatisieren.

[16:35] Wenn du es nicht installiert hast, wenn du zum Beispiel irgendeine Massenverarbeitung auf dem

[16:38] Server machen willst und da ist kein Word installiert, könnte das schwierig werden. Hast du aber eine

[16:43] Textdatei, kannst du dieses Skript, was du da gebaut hast, auf jedem beliebigen System überall

[16:47] ausführen, weil es sind ja eben nur Textdateien. Also Automatisierbarkeit wird ganz, ganz groß

[16:53] geschrieben bei diesen Textformaten und das ist für uns als ITler natürlich super interessant.

[16:57] Beispiel, ich habe vielleicht 50 Blogartikel geschrieben in den letzten Jahren und möchte

[17:02] die jetzt als PDF erzeugen. Wie mache ich das, wenn ich 50 einzelne Word-Dateien habe? Da copy

[17:08] und paste ich mich zu Tode und habe dann am Ende eine Word-Datei mit 200 Seiten. Da ratzt mir

[17:13] wahrscheinlich alle zwei Minuten das Programm ab und das ist doof. Habe ich das alles in zum Beispiel

[17:17] Markdown-Dateien, mache ich ein CAD auf der Kommandozeile, ballere die alle in ein großes

[17:21] Markup-File, hänge die einfach hintereinander, drücke auf Drucken, wenn ich einen Markdown-Prozessor

[17:26] habe und schwupp kommt mein PDF raus. Das heißt, es ist mega einfach, auch eine Massenverarbeitung

[17:31] zu machen, eine Manipulation dieser Dateien zu machen, eben die Automatisierung. Das ist ein

[17:36] sehr großer Vorteil von diesen Plain-Text-Formaten. Also fassen wir nochmal zusammen. Vorteile von

[17:41] Plain-Text-Formaten. Jetzt mal unabhängig auch davon, ob es jetzt für Texte ist oder nicht.

[17:45] Grundsätzlich Plain-Text, also auch XML, HTML, alles was du wirklich in Textformaten ablegst. Die Vorteile

[17:51] sind Versionierbarkeit, Langlebigkeit, Produktivität bei der Arbeit, Flexibilität und Automatisierbarkeit.

[17:59] Und jetzt kommen wir mal zu den konkreten Beispielen, die ich im Alltag benutze und wie ich finde, die

[18:05] ganz sinnvoll sind. Ob du jetzt alle davon zum Beispiel bei dir brauchst oder nicht, ist egal.

[18:08] Nimm das mal als Anregung, guck dir vielleicht mal ein paar davon an und entscheide dann, was für

[18:13] dich das Passende ist. Ich gebe dir zu allen so ein paar Informationen, vielleicht Vor- und Nachteile

[18:17] und dann kannst du entscheiden, ob und wo du sie vielleicht einsetzen willst. Fangen wir vielleicht

[18:22] mal an mit dem Platz hier, schnell nicht mal, und zwar Markdown. Markdown ist im Jahr 2020, wo ich

[18:29] das hier aufnehme, sicherlich eines der verbreitetsten Formate für solche Plain-Text-Markup-Sprachen,

[18:35] die es gibt. Denn das wird einfach von sehr vielen Plattformen unterstützt. Du kannst zum Beispiel

[18:40] auf GitHub, wenn du dort deine Dateien einfach als Markdown-File mit reinlegst, kannst du die

[18:45] direkt in der Web-Oberfläche anzeigen lassen, da werden sie schön gerendert, heißt das dann. Wenn

[18:50] du das Wort vielleicht noch nie gehört hast, beim Rendern geht es immer darum, um aus einem

[18:54] Input-Format ein Output-Format zu machen. Also wenn du zum Beispiel Markdown aufschreibst und,

[18:58] nehmen wir mal ein kleines Syntax-Beispiel, ein Sternchen zu Beginn der Zeile sorgt für eine

[19:02] Aufzählung. Im Plain-Text-Format siehst du halt einfach nur das Sternchen, also diesen Asterisk

[19:07] auf Englisch, und wenn du das Ding jetzt renderst, dann kommt zum Beispiel HTML raus, weil du das

[19:12] schön lesbar darstellen willst, und im HTML wird dann wirklich ein UL mit LI-Element generiert,

[19:18] sodass du also wirklich ein Aufzählungszeichen davon hast. Und dieses Rendering wird also benutzt,

[19:24] um aus dem Input-Format das Output zu machen. Du könntest Markdown jetzt auch als PDF rendern,

[19:28] Standardformat wäre halt eben HTML, oder zum Beispiel aus LaTeX könntest du auch PDF rendern,

[19:33] oder aus Plant-UML, was ich kurz erwähnt hatte, könntest du aus dem Text-Format eben eine Grafik

[19:39] rendern, zum Beispiel ein Klassendiagramm beispielsweise. So, und dieses Rendering wird

[19:44] in vielen Tools einfach nativ unterstützt. Nativ bedeutet, dass es quasi eingebaut ist,

[19:49] dass du also nichts zusätzlich installieren musst, irgendwie ein Plugin oder sonstiges,

[19:52] sondern dass das einfach da ist. Und das ist bei GitHub zum Beispiel so. Wenn du eine Markdown-Datei

[19:56] bei GitHub mit eincheckst und du klickst die an, aber

[20:00] auf der GitHub-Oberfläche, dann wird die direkt nativ gerendert in HTML und du siehst wirklich

[20:05] ein schönes Output, also Beispiel aus dem Sternchen wird jetzt eben eine Liste mit Aufzählungszeichen

[20:11] gerendert.

[20:12] Und das ist in ganz, ganz vielen Plattformen so, nicht nur bei GitHub.

[20:15] Du kannst dich mal umgucken, wenn du das weißt, dann wirst du auch merken, wie viele Plattformen

[20:19] das unterstützen.

[20:20] Zum Beispiel meine To-Do-App, Todoist, die ich benutze, die unterstützt Markdown.

[20:25] Wenn ich in meine Kommentare zum Beispiel Markdown schreibe, dann wird das einfach so

[20:28] gerendert.

[20:29] Oder ich glaube auch zum Beispiel Kanban-Software wie Trello unterstützen das, glaube ich, auch

[20:35] für die Kommentare.

[20:36] Also denk mal dran, sobald du irgendwo das nächste Mal eine Software benutzt, vielleicht

[20:39] unterstützt die sogar schon Markdown, ohne dass du es weißt.

[20:42] Und das kann man relativ einfach ausprobieren.

[20:44] Ich habe jetzt schon das erste Beispiel genannt, eben diese Sternchen zu Beginn der Zeile sorgen

[20:48] dafür, dass es eine Aufzählung wird.

[20:49] Und wenn das in deinem Tool so ist, Sternchen eingeben, dahinter den Text und auf einmal

[20:53] siehst du eine schön gerenderte Liste mit Pünktchen davor, dann weißt du, okay, das

[20:57] Ding unterstützt Markdown.

[20:59] Und wie gesagt, die Liste der unterstützenden Softwaren ist lang.

[21:03] Ich benutze zum Beispiel auf meiner Website ein WordPress-Plugin, weil WordPress das leider

[21:08] noch nicht nativ unterstützt, soweit ich weiß.

[21:10] Und das heißt, meine Blogartikel schreibe ich auch alle in Markdown, kopiere die in

[21:14] den Edehor, drücke auf Speichern und dann sorgt das Plugin dafür, dass aus dem Markdown

[21:17] HTML wird und das vernünftig aussieht.

[21:19] Und das gibt es halt auch für ganz viele andere Plattformen, wird auch in vielen Editoren

[21:24] unterstützt.

[21:25] Ich nehme jetzt mal Visual Studio Code, wo ich nachher noch ein bisschen drauf eingehe

[21:27] und unterstütze das auch perfekt.

[21:29] Es gibt sogar eine Vorschau-Funktion, das heißt, ich schreibe Markdown und auf der

[21:32] rechten Seite wird mir direkt angezeigt, wie es dann in HTML aussehen würde und so weiter.

[21:36] Und das vielleicht ganz kurz, also Output von Markdown ist hauptsächlich HTML.

[21:41] Wurde auch dafür entwickelt, dass man möglichst einfach HTML schreiben kann, denn HTML ist

[21:45] halt dieses mega nervige Format mit öffnendem Tag und schließendem Tag und da hast du quasi

[21:51] mehr Overhead, mehr Tags, als du eigentlich deinen Text hast.

[21:54] Und das ist halt so doof, darum würde ich dir nicht empfehlen, damit Texte zu schreiben.

[21:58] Und Markdown macht das halt deutlich einfacher, da werden halt bestimmte syntaktische Elemente

[22:03] aus HTML in einfacherer Darstellung dargestellt.

[22:07] Also eben das Beispiel, anstatt ul, li, text, li zu, ul zu, machst du einfach Sternchen,

[22:14] Text und hast halt deine Liste mit einem Aufzählungspunkt.

[22:17] Und Markdown bietet nicht alle Möglichkeiten aus HTML, also sowas wie tiefer gestellt,

[22:22] höher gestellt, Fußnoten und ich weiß nicht, was du alle noch machen kannst.

[22:25] Das geht in Markdown nicht, das ist sehr abgespeckt und deswegen empfehle ich es auch

[22:29] zum Einstieg, weil es sehr leicht zu lernen ist.

[22:32] Es gibt einen ganz geringen Sprachumfang, es gibt so klassische Sachen wie Bildereinbetten,

[22:38] sortierte, unsortierte Listen, Überschriften natürlich, Links und verschiedene andere

[22:43] Dinge gibt es, aber so ganz exklusive Sachen wie, keine Ahnung, Canvas, auf dem du rummalen

[22:48] kannst oder so, dafür ist es nicht gedacht.

[22:50] Es gilt wirklich, die zentralen Elemente, die du in so einem Text üblicherweise auf

[22:54] Websites hast, damit abzubilden.

[22:56] Ich habe in den Shownotes zur Episode hier Beispiele für alle Textformate, die ich heute

[23:01] vorstelle, genannt.

[23:02] Schau da gerne mal rein.

[23:03] Die findest du wie immer unter itberufe-podcast.de slash 155 für die 155.

[23:09] Episode heute und Markdown ist meiner Meinung nach das einfachst zu erlernende Format.

[23:15] Also wenn du dir das mal anguckst, okay, wenn du etwas schwierigere Sachen in Anführungszeichen

[23:19] wie Links und Bilder oder so dir anguckst, brauchst du vielleicht 10 Minuten, um das

[23:23] Format zu verstehen.

[23:24] Also es ist wirklich sehr, sehr einfach und danach kannst du halt loslegen und kannst

[23:29] deine Texte damit schreiben und hast eben hauptsächlich als Outputmöglichkeit HTML,

[23:34] aber es gibt eben auch Tools, die daraus direkt einen PDF machen, mit Inhaltsverzeichnis

[23:38] und allem Schnickschnack, was du brauchst, anhand der Überschriften und das ist zum

[23:43] Einstieg wirklich sehr gut geeignet und wird halt in sehr vielen Tools unterstützt.

[23:47] Von daher, das kann ich dir dringend empfehlen.

[23:49] Wenn du es noch nicht gehört hast, guck dir Markdown mal an, das ist ein ganz einfaches

[23:53] Format.

[23:54] Markdown übrigens heißt extra so, als Gegenentwurf zu Markup.

[23:58] Markup ist ja eine Auszeichnungssprache, insbesondere halt HTML und die Erfinder haben

[24:03] sich gedacht, Mensch, HTML ist ja eigentlich ganz cool, ist aber ein mega Overhead mit

[24:06] diesen 1000 Tags und so und deswegen haben sie sich dann Markdown überlegt, ne, Up,

[24:11] ja, verstehst du?

[24:12] Und das ist dann halt der Gegenentwurf, damit es ein bisschen einfacher ist, für dich die

[24:16] Texte zu schreiben.

[24:17] Markdown benutze ich, ohne Scheiß, jeden Tag.

[24:20] Ich schreibe inzwischen fast alles in Markdown.

[24:22] Ich schreibe meinen Newsletter in Markdown, meine Blogartikel, meine Kommentare zum Code,

[24:26] also zum Beispiel in GitHub, ja, das heißt, Markdown ist so omnipräsent bei mir.

[24:31] Ich würde inzwischen einfach erwarten, dass das jeder kennt, ja, ist aber leider noch

[24:34] nicht so.

[24:35] Ich kann dir nur ans Herz legen, dir das mal anzugucken.

[24:37] Kann ich dringend empfehlen.

[24:39] So, das nächste Format wäre dann ASCII-Doc.

[24:42] ASCII-Doc hat bewusst ASCII im Namen, ne, sind halt auch wieder Plain Text der Hinweis

[24:47] da drauf und das Format ist sehr, sehr umfangreich im Vergleich zu Markdown.

[24:51] Also wenn du die Markdown-Syntax in 15 Minuten lernst, ASCII-Doc, da brauchst du deutlich

[24:55] länger.

[24:56] Die Basics sind fast identisch zu Markdown, also Listen zum Beispiel sind auch einfach

[25:00] Sternchen zu Beginn der Zeile, aber ASCII-Doc kann noch so viel mehr.

[25:04] ASCII-Doc kannst du wirklich benutzen, ich sag mal, um komplette Bücher zu schreiben,

[25:07] weil der Sprachumfang ist wirklich riesig.

[25:10] Du kannst auch super cool da mit Dokumentation für Quelltext schreiben.

[25:15] Du kannst mit einfachen Befehlen zum Beispiel Quelltext aus Dateien direkt inkludieren aus

[25:19] der echten Datei.

[25:20] Du kannst so, ja, ich glaub die heißen Callouts machen, wo dann zum Beispiel so ein Ausrufezeichen

[25:24] zu Beginn der Zeile steht, richtig schön gerendert, so um Leute darauf hinzuweisen,

[25:29] dass es hier vielleicht ein Problem gibt beim Verständnis oder sowas.

[25:32] Also du hast richtig viele coole Möglichkeiten, Fußnoten kannst du einfügen, also wirklich

[25:37] ganz viele Sachen, ist aber eben auch ein großer Sprachumfang, d.h. hier musst du wirklich

[25:42] ein bisschen lernen, ein bisschen investieren.

[25:44] Für die Basics, sag ich mal, die man so für seine Texte braucht, Aufzählungen, Überschriften,

[25:50] sowas, geht das auch in 15 Minuten, ja, sieht auch sehr sehr ähnlich aus zu Markdown, muss

[25:54] man ehrlicherweise sagen, aber sobald es dann natürlich darüber hinausgeht und du wirklich

[25:58] lange Texte schreiben willst, dann musst du dich da ein bisschen einarbeiten.

[26:01] Auf der anderen Seite könntest du mit ASCII-Doc zum Beispiel deine Projektdokumentation schreiben,

[26:06] das meine ich jetzt ernst, ja, deine Projektdokumentation für die IHK-Abschlussprüfung, Markdown unterstützt

[26:11] alles, was du dafür brauchst, ja, Listings zum Beispiel, Bilder einbetten, Inhaltsverzeichnis,

[26:16] verlinkte Überschriften, also alles, ja, und deswegen kannst du auch aus ASCII-Doc so

[26:20] ziemlich jedes Output-Format generieren, du kannst HTML erzeugen, ein PDF, richtig schön

[26:25] mit hier klickbarem Inhaltsverzeichnis, was dann auch an der Seite so aufklappen kann

[26:29] und so, du kannst EPUB generieren, also wirklich ein E-Book daraus erzeugen, ja, und das richtig

[26:35] Geile ist für mich als Entwickler, es gibt auch Gradle-Plugins oder Maven-Plugins, wenn

[26:39] du zum Beispiel mit Java entwickelst, gibt es bestimmt auch für andere Plattformen irgendwelche

[26:42] Plugins, ja, aber ich kann zum Beispiel meine Code-Dokumentation in ASCII-Doc schreiben,

[26:48] mit ins Repo packen und dann im Gradle-Build, also in meinem Build-Tool, die Dokumentation

[26:53] erzeugen lassen.

[26:54] Das heißt, als Output bei meinem Compile-Prozess, bei meinem Build-Prozess kommt nicht nur das

[26:58] lauffähige Artefakt raus, also mein JAR-File in Java zum Beispiel, sondern auch ein PDF,

[27:03] wo die ganze Dokumentation drin ist, ne.

[27:04] Ist das nicht geil?

[27:05] Ja, also das macht richtig Bock, so als Entwickler, du dokumentierst was, du schreibst was, drückst

[27:11] auf den Build-Knopf und am Ende kommt ein PDF raus, ist das nicht genial?

[27:15] Also das ist für mich als Entwickler so richtig cool, das ist so nach dem Motto, ich kompiliere

[27:19] meine Dokumentation, ja, und das macht auch Spaß, das heißt, du kannst dich auch wirklich

[27:22] mit dem Build-Prozess auseinandersetzen, du kannst mit Gradle rumfriemeln und Gradle

[27:26] ist jetzt nur ein Beispiel, ja, das gibt's hundertprozentig auch für .NET und PHP und

[27:30] ich weiß nicht was, ja.

[27:31] Das ist nämlich der große Vorteil, Asciidoc, das kommt ursprünglich aus dem Ruby-Umfeld,

[27:36] ist eigentlich ein Ruby-Tool, das heißt Asciidoctor eigentlich ausgesprochen und Asciidoc ist

[27:41] das Format, was da verarbeitet wird und es gibt inzwischen ganz viele Ports für verschiedene

[27:45] Programmiersprachen, also für Java, sicherlich für .NET, PHP und so weiter auch und du nimmst

[27:49] halt dieses Asciidoc als Input, nutzt dann eben den Asciidoctor-Port für deine Programmiersprache

[27:54] und in Anführungszeichen drückst auf den Knopf bzw. du willst es ja automatisieren,

[27:58] also gibst einen Kommandozeilenbefehl ein, zum Beispiel Gradle Asciidoc und dann kommt

[28:02] halt eben dein PDF raus oder dein EPUB oder HTML oder was auch immer du willst, ja.

[28:07] Das heißt, das Ding hat einen super coolen Umfang, du kannst damit richtig fette Bücher

[28:11] schreiben auf, in Anführungszeichen und es ist super automatisierbar, es gibt viele

[28:16] Bildwerkzeuge, die das schon unterstützen, also richtig geiles Format, gefällt mir richtig

[28:20] gut und ich programmiere in Anführungszeichen damit zum Beispiel gerade die Dokumentation

[28:25] für meine Java-Einführung, die ich mit meinen Azubis mache. Das habe ich jetzt auf Asciidoc

[28:29] umgestellt, einfach weil der Sprachumfang so genial ist und gerade weil ich da diese

[28:32] Code-Ausschnitte super reinbauen kann, ja. Beispiel, ich mache irgendwie eine Einführung

[28:36] in die Objektorientierung, habe da so eine kleine Klasse programmiert und anstatt jetzt

[28:39] Copy-Paste zu machen, das in mein Dokument zu packen, sage ich einfach in der Asciidoc-Datei,

[28:43] hey, inkludiere mal bitte diese Java-Datei, die liegt an diesem Pfad, nimm mal Zeilen 17

[28:47] bis 23 und dann habe ich kompilierbaren Code, wo ich weiß, dass er funktioniert und er wird

[28:51] direkt in der Dokumentation benutzt, mit Syntax-Highlighting und allem Schnickschnack,

[28:56] ja. Also Asciidoc kann ich nur empfehlen, unbedingt angucken, ganz tolles Format. So,

[29:01] dann mache ich mal weiter mit einem ganz alten Format, aber weil es so alt ist, auch einem

[29:04] ausgereiften Format und zwar LaTeX. Wenn du dir auf meiner Website mal die Vorlage anguckst für

[29:10] die Projektdokumentation für deine Abschlussprüfung, dann wirst du sehen, die ist in LaTeX entwickelt,

[29:15] gibt es auch alle bei GitHub übrigens, kannst du dir angucken, kannst du gerne einen Pull-Request

[29:19] auch aufmachen, mir irgendwelche Feedback-Sachen zuschicken und so weiter. Das ist auch Plain-Text,

[29:24] das heißt, du kannst mit jedem Text jedes Zeug aufmachen und LaTeX ist ein komplettes

[29:28] Textsatzsystem, das heißt, es gibt perfekten Textsatz in Anführungszeichen, das Ding ist

[29:33] ausgereift, das ist Jahre alt, das ist etabliert und damit kannst du komplette Bücher setzen,

[29:38] inklusive allem, was du brauchst, Index, Inhaltsverzeichnis, Querverweise, Fußnoten

[29:44] natürlich, Listings, Grafiken, alles. Also LaTeX ist ein Textsatzsystem, das ist quasi ein

[29:51] Konkurrenzprodukt zu Word, nur besser. Mit LaTeX kannst du alles machen und LaTeX ist, ich

[29:56] weiß nicht, 20, 30 Jahre alt, funktioniert heute immer noch genau wie früher, das heißt, die

[30:00] Langlebigkeit ist hier einfach das zentrale K.O.-Kriterium. Ich kann Dateien, die ich in

[30:05] meinem Studium erstellt habe vor inzwischen 15 Jahren, heute noch aufmachen und kompilieren

[30:11] und das Ding sieht genauso aus als PDF wie früher. Also das ist wirklich genial und wenn du dir das

[30:17] noch nicht angeguckt hast, dann wird es jetzt Zeit, das zu tun, denn für so eine IHK-Projektdokumentation,

[30:21] wo mal 50 Seiten bei rumkommen, kann ich das nur empfehlen. Die Hürde ist natürlich sehr hoch,

[30:28] denn LaTeX ist schon ein komplexes System, insbesondere weil es halt für, du kannst damit

[30:33] eben Bücher setzen, das heißt, der Sprachumfang ist auch enorm groß. Also du kannst ja nicht

[30:37] einfach mal anfangen, hier Sternchen, du hast eine Aufzählung. Nein, du brauchst sehr viel mehr Befehle.

[30:42] Du brauchst eine komplette Einleitung, in Anführungszeichen, um dein Dokumentformat zu

[30:46] bestimmen. Du musst Seitenränder setzen, so was, Abstände setzen, Schriftgröße und also du musst

[30:53] wirklich viel tun, damit es vernünftig aussieht. Aber die Einarbeitung lohnt sich, denn wenn du das

[30:58] einmal fertig hast, und das habe ich ja schon für dich gemacht mit meiner LaTeX-Vorlage für die

[31:02] Dokumentation, dann musst du nur noch deinen Text einfügen und dann aber eben auch noch die

[31:07] entsprechenden Befehle, um Sachen hervorzuheben, wie zum Beispiel Fettdruck. Und nur mal als Vergleich,

[31:11] LaTeX hat da vom Overhead schon ein bisschen mehr mit HTML gemeint, wie mit den anderen Sprachen.

[31:16] Also ich nehme jetzt mal nur das Beispiel Fett, ja, da würdest du in Markdown zum Beispiel einfach

[31:21] Sternchen um das Fette-Wort machen. Also, keine Ahnung, dies ist ein Text und Text soll Fett. Dann

[31:27] würdest du schreiben, dies ist ein Sternchen, Sternchen, Text, Sternchen, Sternchen und dann würde Text

[31:32] Fett gedruckt. Bei ASCII-Doc reicht ein Sternchen, ja, wäre es also Sternchen, Text, Sternchen und

[31:36] andere Formate machen das vielleicht noch anders. In LaTeX brauchst du wirklich einen Befehl dafür und

[31:40] der heißt zum Beispiel backslash text bf, geschweifelte Klammer auf, dann kommt der Text, geschweifelte

[31:45] Klammer zu. Das heißt, du musst schon ein bisschen mehr tippen und eingeben, als du das bei den anderen

[31:51] Formaten machen müsstest. Immer noch schöner, als mit Word zu arbeiten, weil du es halt einfach

[31:55] eintippen kannst, ja, und nicht irgendwie markieren, Formatvorlage auswählen, also klicky-klicky. Von daher,

[32:01] LaTeX ist mein absolutes Lieblingsprogramm immer noch, wenn ich komplexe, ja, Bücher fast setzen

[32:06] will, ist aber eben auch ein ziemlicher Overhead und du brauchst halt auch ein Tool, also du brauchst

[32:10] eine LaTeX-Distribution, um dann wirklich dein Dokument auch übersetzen zu können. Und da gibt es

[32:15] ganz viele Plug-ins und erweiterte Bibliotheken, die du brauchst und so weiter und so fort. Das

[32:19] heißt, die Infrastruktur ist schon ein bisschen komplexer, als wenn ich das mal mit Markdown

[32:23] vergleiche, wo du wirklich nur einen Texteditor brauchst und kannst loslegen, ja. Also von daher, LaTeX,

[32:28] ich kann es dir dringend empfehlen, guck's dir an. Meine Azubis benutzen das zum Beispiel, um ihr

[32:32] Berichtsheft zu erstellen, ja. Also du kannst damit supergeile Sachen machen. Die Einstiegshürde ist aber

[32:37] relativ groß, weil du dich da wirklich einarbeiten musst, ja. Also nur zum Vergleich, zu LaTeX gibt es

[32:42] ganze Bücher, die erklären, wie man vernünftig mit LaTeX arbeiten sollte, ja. Einfach, weil es so umfangreich

[32:47] ist. Nichtsdestotrotz, ich empfehle das, guck dir das an. Das Ding ist richtig geil, ja, ist aber eine

[32:54] große Hürde, wie gesagt. Ja, und das letzte Format für heute wäre plant.uml. Das ist eine kleine

[33:00] Subsprache, in Anführungszeichen, nur für UML-Diagramme. Das heißt, du kannst hier auf Plain-Text-Ebene deine

[33:08] Klassendiagramme zum Beispiel beschreiben oder Aktivitätsdiagramme, Use-Cases, was auch immer. Das

[33:11] unterstützt sehr viele Diagrammtypen. Und wie kannst du dir das vorstellen? Beim Klassendiagramm ist es

[33:16] vielleicht noch am einfachsten zu verstehen, wenn du grob so eine Syntax von C-sharp, Java, PHP im Kopf

[33:22] hast, also irgendwie class Auto, Geschweife, Klammer auf und dann irgendwie deine Variablen, Geschweife,

[33:26] Klammer zu und so. Im Prinzip so ähnlich sieht ein Beispiel in plant.uml aus, ja. Und dann drückst du

[33:33] quasi auf den Knopf und plant.uml macht daraus ein PNG, ein JPEG, was auch immer du haben willst. Und das

[33:38] sieht dann wirklich so aus wie ein UML-Diagramm, wie du es kennst. Also die Klasse Auto wird dann

[33:43] wirklich als Rechteck dargestellt mit den zwei waagerechten Strichen, wo die Attribute und Methoden

[33:48] darunter stehen und so weiter. Das heißt, du tippst deine Klasse ein. Im besten Fall kannst du sie fast

[33:54] eins zu eins aus deinem Code kopieren, ein bisschen anpassen, weil die Syntax nicht hundertprozentig so ist

[33:59] wie Java, aber sehr, sehr, sehr ähnlich. Und dann kommt halt auf Knopfdruck ein schönes Bild raus. Und das ist

[34:04] natürlich auch mega cool, wenn du das dann benutzt, um zum Beispiel deinen Code zu dokumentieren,

[34:09] beispielsweise in Verbindung mit Asciidog. So habe ich das jetzt gemacht. Dann schreibst du deine

[34:13] Dokumentation in Asciidog und dann gibt es ein Plugin für Asciidog, was direkt plant.uml in die

[34:17] Sprache integriert. Das heißt, du kannst jetzt sowas sagen, so Sternchen, so im folgenden Beispiel siehst du

[34:22] jetzt die Klasse als Diagramm und dann machst du Enter und gibst irgendwie sowas ein wie, ich sage

[34:28] jetzt mal in Anführungszeichen, jetzt kommt plant.uml, dann tippst du deine Klasse ein, Ende plant.uml und dann

[34:34] kannst du mit dem Asciidog-Übersetzer daraus ein PDF machen, wo dann zum Beispiel das plant.uml-Diagramm

[34:39] direkt als Grafik drin ist. Das heißt, du kannst es nahtlos integrieren, schreibst Asciidog rundherum,

[34:44] sagst dann jetzt kommt plant.uml, machst dein Diagramm, machst es wieder zu und weiter geht's. Und das ist

[34:50] mega easy, alles plaintext, alles versionierbar, alles an einer Stelle und das ist einfach mega

[34:55] cool. Und auch dafür gibt es sehr, sehr viele Plugins für Plattformen, wie zum Beispiel die

[35:00] Projektverwaltungssoftware, die ich erwähnt hatte, Redmine, die wir in der AO zum Beispiel einsetzen

[35:05] in der Firma, die hat ein Plugin dafür. Das heißt, du kannst sogar in deinen Wiki-Seiten oder deinen

[35:10] Tickets zum Beispiel ein plant.uml-Diagramm reinschreiben und die Oberfläche rendert das dann für

[35:16] dich und zeigt dir das als schönes Diagramm an. Und das ist natürlich mega cool, wenn du in deinem

[35:19] Ticket zum Beispiel schreibst, hey, ich habe hier ein Workflow, keine Ahnung, so eine kleine

[35:22] Aktivitätsdiagrammzeichnung oder so, kannst du einfach runterschreiben, drückst auf speichern und in

[35:27] der HTML-Seite findest du eine schön gerenderte Grafik, um das darzustellen. Also mega cool, das

[35:31] kann ich nur empfehlen, wenn du irgendwas mit Dokumentation machen musst, gerade im Entwicklungsumfeld

[35:36] plant.uml, richtig coole Sache. Die Syntax ist für die einzelnen Diagrammtypen ähnlich, aber schon

[35:43] noch ein bisschen, natürlich, weil die Diagramme auch unterschiedlich aussehen, ein bisschen anders.

[35:47] Das heißt, du musst da schon ein bisschen Zeit investieren, aber um mit so einem simplen

[35:50] Klassendiagramm zum Beispiel anzufangen, das schaffst du in 10 Minuten. Die Basic-Syntax hast

[35:55] du drauf und du kannst dann schon mal anfangen, deine Software damit zu dokumentieren. Also

[35:59] richtig, richtig gut, kann ich nur empfehlen, schau dir das mal an. Ja, und jetzt fällt mir

[36:03] gerade auf, dass ich noch ein Format vergessen habe, und zwar Textile, das habe ich einfach

[36:07] übersprungen. Textile hat auch den Ansatz wie Markdown möglichst einfach zu sein und wurde

[36:12] auch erfunden, quasi um von diesem HTML-Zeug wegzukommen. Die Syntax ist ein bisschen anders

[36:17] als bei Markdown, man merkt aber noch die HTML-Einflüsse. Also mal als Beispiel, in Markdown

[36:22] wird eine Überschrift einfach mit einem Hash, also mit dem Lattenzaun quasi gemacht, Lattenzaun

[36:26] Überschrift, dann hast du deine Überschrift. In Textile wird das zum Beispiel mit h1 Punkt oder

[36:32] h2 Punkt gemacht. Und wenn du HTML kennst, h1, h2 sind ja die Tags für Überschriften. Das heißt,

[36:37] Textile ist noch ein bisschen dichter dran als HTML, was ich persönlich aber ein bisschen blöder

[36:42] finde als bei Markdown, denn normale Menschen, die HTML nicht kennen, die fragen sich, hä, h1, h2,

[36:47] was soll das denn? Und bei Markdown machst du einfach Hash oder Doppel-Hash für Überschrift

[36:51] 2. Das ist also, finde ich, einfacher zu erklären und einfacher zu lesen. Deswegen

[36:56] bevorzuge ich Markdown, ja. Aber vom Umfang ist Textile vergleichbar mit Markdown, kann auch

[37:02] was Markdown kann, die üblichen Sachen, Verlinkung, Überschriften, FAT, Kursiv,

[37:07] etc. kann es auch. Und ich benutze es eigentlich hauptsächlich deswegen, weil ich gezwungen werde,

[37:12] nämlich Redmine, unsere Projektverwaltungssoftware, unterstützt leider nur das und nicht Markdown.

[37:16] Deswegen muss ich es können quasi. Aber wenn ich die Wahl hätte, würde ich auf jeden Fall

[37:23] Markdown bevorzugen, einfach weil es viel verbreiteter ist. Ich hatte schon gesagt,

[37:25] GitHub und so weiter. Textile kann sein, dass einige Plattformen das unterstützen,

[37:29] aber ich glaube, Markdown hat bei weitem die größere Verbreitung. So, das waren die Beispiele

[37:35] für konkrete Markup-Formate. Ich fasse nochmal zusammen. Markdown unbedingt angucken, super

[37:40] einfach zu lernen, wird fast überall unterstützt. Asciidoc, mega großer Sprachumfang, perfekt für

[37:45] technische Dokumentation. Du kannst ganze Bücher damit setzen lassen. Textile, nettes Ding. Wenn

[37:50] ich die Wahl hätte, würde ich Markdown nehmen. LaTeX, komplettes Textaussystem, mit dem du perfekt

[37:55] Texte setzen kannst. Aber die Einstiegshöhe ist sehr groß und plant alles, was du mit UML-Diagrammen

[38:01] machen willst, kannst du damit tun und lässt sich insbesondere zum Beispiel in Asciidoc perfekt

[38:06] integrieren. So, jetzt habe ich aber gerade schon gesagt, Textile finde ich eigentlich blöd, ich

[38:11] würde es lieber in Markdown machen, kann ich aber nicht, weil die Plattform das nicht unterstützt.

[38:14] Und jetzt kommen wir zum weiteren Vorteil dieser Formate, denn, ich hatte gerade schon gesagt,

[38:18] oder gerade zu Beginn, so diese Flexibilität, die die Formate mir erlauben, die kann ich jetzt

[38:24] hier ausspielen. Und zwar, wenn ich gewohnt bin, Markdown zu schreiben, dann kann ich das jetzt

[38:27] weiter tun. Wenn ich jetzt aber als Zielplattform Redmine zum Beispiel habe, wo ich Texteil brauche,

[38:31] dann kann ich das ja automatisieren und die Formate einfach ineinander übertragen. Und

[38:37] dafür gibt es ein mega cooles Tool, das ich unbedingt empfehlen möchte, und das heißt

[38:40] Pandoc. Und das konvertiert automatisch Dateien von beliebigen Inputformaten in beliebige Outputformate.

[38:49] Das heißt, ich könnte sowas sagen wie Pandoc, also das ist jetzt nicht die exakte Syntax,

[38:54] aber nur zum Verständnis. Pandoc minus Input, Markdown, minus Output, Texteil. Und dann schreibe

[39:00] ich die Datei dahin und dann nimmt er die Markdown-Datei, liest die ein und konvertiert

[39:05] die in Texteil ins andere Format, aber in der gleichen Struktur natürlich. Also Beispiel,

[39:11] wenn du in Texteil vielleicht Code-Blöcke mit At-Zeichen umschließen musst, in Markdown die

[39:17] aber mit einem, was auch immer für ein Akzent es ist, Graf oder Tegül, ich weiß es nicht,

[39:22] auf jeden Fall macht es dann quasi diese Konvertierung für dich. Also sieht Markdown,

[39:26] oh, das ist ein Code-Block, dann konvertiert er das in die entsprechende Texteil-Syntax und macht

[39:30] halt die Zeichen an, dass sie dafür benutzt werden. Und das ist mega, mega gut, denn das heißt,

[39:34] du kannst auf der Konsole einfach aus deinem Markdown dein Texteil machen, kopierst das Texteil,

[39:38] packst es in Redmond rein und bist fertig. Das heißt, egal welches Markup-Format du benutzt,

[39:44] mit Pandoc kannst du es ineinander umwandeln. Und ich meine wirklich, egal welches. Du kannst mal

[39:49] auf die Website gehen von Pandoc, alles in den Show Notes verlinkt, da findest du, ich glaube,

[39:52] über 40 Formate, die Pandoc verarbeiten kann. Das ist mega geil. Dieses Tool ist wirklich richtig

[39:58] gut. Du kannst unter anderem auch LaTeX erstellen lassen. Ich glaube, sogar Word-Dateien sind

[40:03] inzwischen möglich. Also Pandoc ist ein mega Ding. Wenn du das noch nie gehört hast,

[40:06] unbedingt angucken, denn da kannst du wirklich, und das Ding ist auch rattenschnell, Formate

[40:10] ineinander umwandeln. Das ist genau das Problem. Wenn deine Plattform dein Lieblingsformat nicht

[40:15] unterstützt, dann hast du jetzt keine Ausrede mehr, denn du nutzt einfach dein Lieblingsformat

[40:18] Pandoc, einen Aufruf und du kannst das Zeug dann in deiner Plattform benutzen. Also unbedingt angucken.

[40:24] Ansonsten ein Tool, was ich empfehlen kann, ist Visual Studio Code. Inzwischen wirklich

[40:28] ein sehr cooler Editor, der von Microsoft verkommt. Visual Studio war ja die

[40:32] original Entwicklungsumgebung von Microsoft, aber der Editor hat damit nicht

[40:36] mehr viel zu tun. Also es ist wirklich ein eigenständiges Produkt und es ist

[40:39] halt auch kostenfrei erhältlich und unterstützt so ziemlich jedes Format, was

[40:43] ich heute erwähnt habe. Insbesondere auch Markdown, super Integration. Da habe ich

[40:47] schon gesagt, du kannst eine Preview-Funktionalität, du kannst das Zeug

[40:50] direkt aus dem Editor als HTML exportieren zum Beispiel. Wenn deine

[40:54] Plattform gar kein Markup-Format unterstützt, machst du Visual Studio Code auf, gibst

[40:58] Markup ein und machst rechtsklick Export als HTML oder so und kannst das HTML

[41:02] irgendwo reinpasten. Also der Editor ist mega gut, hat natürlich auch Syntax-Highlighting,

[41:07] hat sogar einen Linter für Markdown, was ich richtig gut finde. Linter, wenn du das

[41:11] noch nie gehört hast, ist ein Tool, was deine Code-Qualität quasi prüft und dir

[41:15] Verbesserungsvorschläge macht und ist jetzt mal nur ein Beispiel. Am Ende einer

[41:20] Markdown-Datei sollte es zum Beispiel ein Zeilenumbruch sein. Wenn du den vergisst,

[41:24] dann meckert Visual Studio Code rum, macht da so eine gelbe Schlange drunter und sagt

[41:28] Hallo, bitte Zeilenumbruch einfügen. Also das Tool ist richtig, richtig gut, zeigt

[41:32] dir also auch Syntax-Fehler, Verbesserungsvorschläge und so weiter und

[41:35] eben diese Preview-Funktion finde ich auch sehr gut und dann kannst du beim

[41:38] Tippen direkt sehen, wie es zum Beispiel in HTML nachher aussehen würde und ob

[41:41] du es richtig gemacht hast. Also super Sache, kann ich nur empfehlen.

[41:44] Ansonsten gibt es noch weitere konkrete Tools für einzelne Sprachen. Ich habe

[41:48] zum Beispiel lange Zeit Markdown-Pad benutzt. Das ist ein Editor speziell nur

[41:52] für Markdown und der hat auch gerade den großen Vorteil, dass ich mit

[41:55] Rechtsklick sagen kann Copy as HTML und dann kann ich eben das HTML irgendwo

[41:59] reinpasten. So habe ich zum Beispiel ganz viele Jahre lang inzwischen mein

[42:03] Newsletter geschrieben. Mailchimp, meine Mail-Software, die ich dafür benutze,

[42:07] unterstützt kein Markup, also kein Markdown oder sonst irgendwas. Das heißt,

[42:10] ich musste immer HTML in die E-Mails pasten und das habe ich dann mit dem

[42:13] Markdown-Pad gemacht. In Markdown geschrieben, Rechtsklick, Copy as HTML,

[42:17] rüber in die E-Mail und fertig war ich. Und dafür gibt es natürlich noch

[42:21] verschiedene weitere Editoren, die speziell für einzelne dieser Sprachen

[42:24] geeignet sind. LaTeX zum Beispiel gibt es irgendwie fünf verschiedene Editoren,

[42:27] die man nutzen kann. Du kannst es in Eclipse machen oder auch mit Visual

[42:31] Studio Code natürlich. Also das ist eben, wie gesagt, der Vorteil. Den siehst du

[42:35] jetzt hier, dieser Markup-Sprachen. Plaintext, du kannst irgendeinen Editor

[42:38] nehmen. Der, der dir einfach am besten gefällt, den nimmst du und du musst

[42:42] dich nicht darum kümmern, da großartig noch irgendwie eine andere Software zu

[42:45] installieren oder sowas. Gut, damit wäre ich jetzt heute fertig. Ich habe viel

[42:49] länger gequatscht, als ich es gedacht hätte, zu diesem kleinen Thema. Ich hoffe,

[42:53] ich konnte ein bisschen was näher bringen, warum du dir das unbedingt

[42:56] angucken solltest, so ein Plaintext-Format. Und ich empfehle, wie gesagt, kurze

[42:59] Zusammenfassung, Markdown zum Einstieg, weil es einfach so weit verbreitet ist.

[43:03] Und wenn du dann so ein bisschen auf den Geschmack gekommen bist, dann guck dir mal

[43:05] die anderen Sachen an. Für Entwickler empfehle ich unbedingt ASCII-Doc und

[43:09] Plant-URL. Und sobald du dich deiner Projektdokumentation näherst im dritten

[43:12] Ausbildungsjahr, unbedingt mal LaTeX angucken. Noch hast du vielleicht genug

[43:16] Zeit, um dich da einzuarbeiten. Wie gesagt, die Hürde ist hoch, aber je früher du

[43:20] anfängst, umso wahrscheinlicher ist es, dass du deine Projektdokumentation

[43:22] super damit umsetzen kannst. Als Editor empfehle ich Visual Studio Code oder ganz

[43:27] klassisch den VI natürlich. Der geht auch. Der hat auch viele Erweiterungsmöglichkeiten

[43:31] für die einzelnen Markup-Sprachen hier. Aber wie gesagt, du kannst irgendeinen

[43:35] Editor nehmen, ist ganz egal. Als letztes noch eine kurze Literaturempfehlung. Ich

[43:39] hatte es am Anfang schon erwähnt. Pragmatic Programmer, ein fantastisches

[43:43] Buch. Nicht nur durch dieses eine Kapitel zum Thema Plaintext ist das zu

[43:47] meiner Empfehlung geworden, sondern auch alles andere darin kannst du wunderbar

[43:50] nutzen, um dich ein bisschen weiterzuentwickeln.

[43:53] Es geht da nicht um konkrete Programmiersprachen, sondern es geht eher

[43:55] um die Idee des Softwareentwicklers, welche Tools er einsetzen sollte, wie er

[43:59] bei der Arbeit grundsätzlich vorgehen sollte und so weiter. Und eben eines

[44:02] dieser Kapitel ist Plaintext. Ein anderes wäre zum Beispiel Versionsverwaltung,

[44:06] warum das sinnvoll ist. Also es geht da wirklich um so absolute Grundlagen, die

[44:09] für viele Softwareentwickler einfach relevant sind und deswegen kann ich das

[44:12] uneingeschränkt empfehlen, dieses Buch. Sowohl die alte Version als auch die

[44:17] neue. Die neue ist natürlich ein bisschen moderner gemacht. Da wird auch mal von

[44:20] GIT geredet. Das gab es vor 20 Jahren noch gar nicht. Von daher, wenn du dich

[44:23] entscheidest, nimm die neuere Version. Die ist natürlich viel relevanter als die

[44:27] alte. Aber auch die alte war schon sehr sehr gut.

[44:29] Ja, damit wäre ich jetzt mit dem Thema fertig. Ich hoffe, ich konnte mich ein

[44:33] bisschen davon überzeugen, dass du dir Plaintext-Formate mal anguckst. Würde mich

[44:37] freuen, wenn ich dir vielleicht so einen kleinen Einstieg hier ermöglicht habe.

[44:40] Wenn du noch ein ganz anderes Format vielleicht einsetzt, was ich nicht genannt

[44:43] habe heute, freue ich mich natürlich über dein Feedback. Wenn du noch ein

[44:46] Format hast, was viel viel besser ist als alle, die ich heute genannt habe, dann

[44:49] her damit. Schreib mir eine Mail, schreib mir einen Kommentar unter die Episode.

[44:52] Shownotes mit Quelltext-Beispielen für alle Sprachen, die ich heute erwähnt

[44:57] habe, findest du unter itberufepodcast.de

[45:01] slash 155. Und da findest du auch alle Sprachen konkret verlinkt. Also kannst

[45:05] du dich die Syntax im Detail angucken. Und auch die Tools, die ich erwähnt habe, sind

[45:08] natürlich alle dort verlinkt. Also schau da gerne mal rein und bei der

[45:12] Gelegenheit lass mir gerne einen Kommentar da.

[45:14] Ja, in dem Sinne, dann bin ich fertig. Ich sage für heute erst mal vielen Dank für

[45:19] die Aufmerksamkeit und bis zum nächsten Mal. Tschüss!