CodiMD + Markdown

Die CodiMD-Software der GWDG (Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen) ermöglicht kollaboratives Bearbeiten von Dokumenten in Echtzeit. ‘MD’ steht hierbei für die Sprache Markdown. Diese Lösung scheint von Etherpad inspiriert worden zu sein, welches ich bereits einmal im Rahmen einer Gruppenarbeit genutzt habe (als Alternative zu Google Docs). codimd

In BAIN wird diese Installation für die Erstellung und das Publizieren der Skripte verwendet, wobei sich diese aufgrund der erwähnten Funktionalitäten stark von den üblichen statischen PPT-Folien und PDFs von Dozierenden unterscheiden. In BAIN ist durch CodiMD vielmehr ein gemeinsames Dokument zwischen Dozenten und Studierenden vorhanden, das von allen editiert und somit auch als Austauschplattform genutzt werden kann. Diese Form von Vorlesungsskript war mir bis anhin neu und ich muss zugeben, dass es stets etwas Überwindung braucht, bis ich mich an neue Software oder Sprachen heranwage. Dementsprechend beruhigt hat mich der Hinweis seitens Lohmeier, dass wir Markdown spielerisch “nebenbei” erlernen und während des Unterrichts bereits kleinere Editieraufgaben im Dokument gestellt wurden. Dass diese Form von Skript Vorteile mit sich bringt, ist immerhin sofort klar: Änderungen können sofort übertragen werden und somit sind alle immer auf dem aktuellen Stand. Im Gegensatz dazu muss bei PPT- bzw. PDF-Skripts jeweils eine neue Version auf Moodle hochgeladen werden. Auf den ersten Blick scheint es also, dass mit CodiMD sehr effizient gearbeitet werden kann. Und wenn man sich erst einmal mit Markdown vertraut gemacht hat, möchte man sich vermutlich auch nie mehr mit PPT-Layout-Problemen herumschlagen müssen.

Lerntagebuch mi GitHub Pages

Für das Lerntagebuch habe ich mich für GitHub Pages entschieden, da ich WordPress bereits kenne und mich die zur Verfügung gestellte, detaillierte Anleitung sehr zuversichtlich stimmte. Mit dieser Anwendung lassen sich Webseiten direkt aus dem GitHub-Repository generieren und auf den Servern von GitHub kostenlos publizieren. Für die Transformation der Dateien in statische Webseiten nutzt GitHub Pages Jekyll. Ausserdem bot mir Gaby Support an, falls beim Einrichten des Blogs Schwierigkeiten auftreten sollten. Tatsächlich hatte ich das Problem, dass nur gewisse Beiträge im Web-Blog angezeigt wurden und wäre wohl ohne Gabys Hilfe nicht so schnell darauf gekommen, dass der Fehler in einem Detail lag: Underscore _ in Dateinamen ist verboten (stattdessen - verwenden)! Ansonsten hat die Einrichtung des Blogs sehr gut geklappt und ich habe Freude daran, jede kleine Änderung sofort auf der Page zu begutachten. Das Template ist nun nicht besonders hübsch aber immerhin unaufdringlich, sodass ich mich schnell damit anfreunden kann. Vermutlich gäbe es die Möglichkeit, Änderungen im Aussehen vorzunehmen, aber das erspare ich mir vorerst – wer weiss, vielleicht kommt das ja noch.

Warum GitHub Pages mit Jekyll? Die wichtigsten Eigenschaften im Überblick:

  • Keine Datenbank: Im Gegensatz zu WordPress und anderen Content-Management-Systemen verfügt Jekyll über keine Datenbank. Dies erweist sich als Vorteil bezüglich der Ladegeschwindigkeit, da beim Laden der Seiten keine Datenbankaufrufe erfolgen müssen.
  • Kein CMS: Es wird kein CMS benötigt, die Inhalte werden einfach in MarkDown in Dateien geschrieben.
  • Schnell: Jekyll ist schnell, da sich keine Datenbank im Hintergrund befindet und nur statische Webseiten erstellt werden.
  • Reduziert: Die Anwendung ist auf das Wesentliche reduziert, insbesondere sind keine Funktionen integriert, die man nicht braucht.
  • Sicher: Viele Schwachstellen, die Plattformen wie WordPress betreffen, gibt es nicht, da Jekyll keine Datenbank, kein CMS und kein PHP hat. Dadurch entfällt auch der Aufwand für Sicherheitsupdates.
  • Bequemes Hosting: GitHub Pages hostet die Jekyll-Website kostenlos und übernimmt gleichzeitig die Versionskontrolle.

Spickzettel für die wichtigsten Formatierungen: MarkDown Syntax

Arbeitsumgebung (Linux)

Damit wir auf unseren eigenen Computern keine Bibliotheks- und Archivsoftware installieren müssen, erhalten alle Studierenden eine virtuelle Maschine der FHGR mit Ubuntu Linux (Version 20.04 LTS). Ubuntu wiederum basiert auf dem Betriebssystem Debian. Ich begrüsse es sehr, dass wir diese nicht auf unseren eigenen Rechnern installieren müssen, da dies bei mir in Vergangenheit immer zu Problemen geführt hat. Ich gebe zwar zu, dass die Schuld zum grössten Teil bei mir liegt; ich bin mit einem lediglich 4 GB MacBook Air ausgestattet und daher fast schon fahrlässig im Studium unterwegs. Der Arbeitsspeicher lässt sich nicht ausbauen und wäre bei meinem alten Modell (2012, aber immer noch einwandfrei!) auch wenig sinnvoll. Probleme sind jedoch nicht nur bei mir aufgetaucht und ich kann mich daran erinnern, dass die Installation jeweils sehr mühselig war und stets viel Unterrichtszeit und Support beanspruchte.

Linux-Server sind meist mit gar keiner grafischen Oberfläche ausgestattet, sondern werden direkt über die Kommandozeile bedient. Warum? Einerseits aus Effizienz- und Traditionsgründen, vor allem jedoch aufgrund der IT-Sicherheit: Grafische Oberflächen können Sicherheitslücken enthalten, weshalb diese in Linux ausgeschaltet ist.

Spickzettel für die wichtigsten Kommandos: Library Carpentry Reference


Quellen: Website GWDG, Vorteile von Jekyll, BAIN-Skript 1