Die Art, sich elektronisch zu vernetzen und zu kommunizieren, hat sich in den vergangenen Jahren stark verändert. Soziale Netzwerke sind an die Stelle von Email getreten und Smartphones zu den zentralen Eingabegeräten geworden. Die Kommunikation in diesen Netzwerken verzichtet auf Schnörkel und kann binnen Kurzem viele Akteur_innen einbinden. Insbesondere in der aktuellen Zeit, in der die meisten Personen im Homeoffice arbeiten, gewinnen niederschwellige, zum Teil auch informelle Kommunikationswege an Bedeutung. Aber auch in entspannteren Zeiten haben soziale Netzwerktools in Lehre und Forschung schon ihren Platz eingenommen (vgl. Perkel, 2016 und Hand, 2016a, 2016b).

Am Institut für Technische Bildung und Hochschuldidaktik (ITBH) haben wir 2016 Mattermost eingeführt, um das Potenzial eines modernen Chattools zu testen. Slack schied nicht zuletzt aufgrund seines Geschäftsmodells und seiner Datenschutzbedingungen aus. Mattermost ist freie Software und damit auch mit der Policy für Offenheit in Forschung und Lehre der TUHH vereinbar. Waren anfangs nur wenige Kolleg_innen aktiv, wächst deren Zahl mit jedem neuen Projekt an. Die Akzeptanz von Mattermost als zentralem Kommunikationswerkzeug gelang vor allem mit einer persönlichen Einführung in die Anwendung des Tools und einem gemeinsamen Aushandlungsprozess, wie es allen Beteiligten den größten Nutzen bringt – und mit Geduld. Da es direkt mit der GitLab-Instanz der TUHH verbunden ist, ergeben sich weitere positive Effekte in der Projektkoordination.

Projektkommunikation im Team

Die oberste technische Ordnungseinheit ist in Mattermost das Team. Ob Teams nach außen sichtbar und frei zugänglich sind, kann individuell entschieden werden. Es macht Sinn, die Teilnahme an einem Team über Einladungen zu steuern, da bei aller gewünschten Transparenz oft Interna verhandelt werden. An der TUHH sind mittlerweile mehrere Institute in Mattermost-Teams organisiert und beziehen auch externe Partner_innen bspw. in Drittmittelprojekten mit ein.

Für den Austasch zur digital gestützten Lehre an der TUHH wurde im März 2020 das hochschulweite Team OnlineEduTUHH eingerichtet. Eine Einleitung zur Anmeldung für dieses Team gibt es in den Praktischen Tipps für das Umstellen der Präsenzlehre an der TU Hamburg.

Transparent kommunizieren

Mattermost kennt drei Abstufungen von Transparenz im Team:

• Öffentliche Kanäle. Öffentliche Kanäle können von allen Teammitgliedern angelegt und abonniert werden. Die Kommunikation in einem öffentlichen Kanal kann von allen mitgelesen und mitgestaltet werden, die ihn abonniert haben. So lässt sich die Kommunikation im Projekt thematisch ordnen und offen führen (vgl. Abb., (1)).
• Private Kanäle. Soll es in einem Team Bereiche geben, in denen nur eingeladene Mitglieder kommunizieren, können private Kanäle eingerichtet werden. Diese sind unsichtbar für Außenstehende und können bspw. vom Dozententeam verwendet werden, wenn Mattermost in der Lehre zum Einsatz kommt (vgl. Abb., (2)).
• Direktnachrichten. Für einen direkten Austausch zwischen allen Nutzer_innen von Mattermost an der TUHH steht letztlich die Funktion zur Verfügung, Direktnachrichten zu verschicken. Es können auch adhoc-Gruppen kommunizieren, indem mehrere Teilnehmende in einen Chat mit Direktnachrichten einbezogen werden (vgl. Abb., (3)).

Nachrichtenflut organisieren

Insbesondere wenn viele Menschen in einem Team zusammenkommen, kann es leicht passieren, dass einzelne Nachrichten untergehen. Dagegen gibt es einige leichte Tipps und Tricks, die den Umgang mit vielen Nachrichten vereinfachen:

• Anzeigen ungelesener Nachrichten: Oben links in der Seitenleiste kann man durch Klick auf den eigenen Namen die Kontoeinstellungen Unter Seitenleiste > Kanalgruppierung und -sortierung einfach einen Haken bei „Ungelesene separat gruppieren“ setzen und schon werden ungelesene Nachrichten oben in der Seitenleiste gebündelt dargestellt.
• Direkte Ansprache von einzelnen Personen: Wenn einzelne Personen in einem Kanal direkt angesprochen werden, kann dies über @benutzername gemacht werden. Der Vorteil ist, dass die Person direkt eine Benachrichtigung darüber bekommt.
• Antworten auf Nachrichten: Um die unterschiedlichen Gesprächsstränge in einem Kanal etwas zu strukturieren, sollten Antworten auf eine Nachricht über den Antwortpfeil rechts neben der Nachricht erfolgen. So werden alle Nachrichten und Antworten zu einem Thema in einem sogenannten Thread zusammengefasst.
• Markieren von zentralen Nachrichten: Zentrale Nachrichten, die für alle Teammitglieder interessant und relevant sind, können manuell mit einem digitalen Pin versehen werden, damit sie unter der Fülle von Nachrichten nicht untergehen. Diese gepinnten Nachrichten können in dem jeweiligen Kanal über das Stecknadel/Reißzwecken-Symbol oben rechts eingesehen werden.

Dateiablage individuell aushandeln

Wenngleich Mattermost die Möglichkeit bietet, auch Dateien im Chat zu teilen, empfiehlt es sich, davon wenig Gebrauch zu machen. Denn die Erfahrung zeigt, dass die Dateien schlecht wiedergefunden werden können, wenn sie erst einmal im Stream verschwunden sind. Auch ist oft nicht klar, welches die letzte verlässliche Version einer Datei ist.

Aus diesen Gründen sind wir dazu übergegangen, Dateien an anderen Orten zu speichern, und im Chat nur die Orte zu benennen, wo sie zu finden sind. Dieses Vorgehen ermöglicht allen Beteiligten, in ihren Projekten die Orte der Dateiablage individuell auszuhandeln. Nextcloud oder GitLab an der TUHH kommen hier in Frage, aber auch proprietäre Dienste von Drittanbietern.

Proaktives und empathisches Teilen

Wie Hand (2016b) aufzeigt, kann die Kommunikation in Tools wie Mattermost die Empathie für andere Teammitglieder und deren Aufgaben erhöhen. Während Linkempfehlungen per Mail noch nie gut gelitten waren, sind Hinweise auf Quellen, die andere im Team interessieren könnten, in Mattermost keine Last, sondern eine Bereicherung. Am ITBH pflegen wir in diesem Sinne das proaktive Teilen von Informationen, von denen wir denken, andere sollten sie auch haben. Sich dafür zu bedanken, ist nicht unbedingt notwendig, kann aber sehr unaufwändig mit einem Emoji geschehen.

Aktivitäten im Blick behalten

Mattermost wirbt damit, mehrere hundert Apps von Drittanbietern integrieren zu können. Wir nutzen dieses Potenzial am Institut bisher nicht, weil noch niemand danach verlangt hat. Eine Integration, die wir intensiv nutzen und die Entwicklungsgeschwindigkeit von Text- und Softwareprojekten sehr beschleunigt, ist GitLab. In dedizierten Bot-Kanälen lassen wir uns über Ereignisse in GitLab informieren. Wenn bspw. jemand ein neues Issue anlegt, Dateien ergänzt oder neu hochgeladen werden oder Buildpipelines scheitern, meldet GitLab das Ereignis in Mattermost. So können wir schnell darauf reagieren.

Mattermost spielt seine Stärken in der synchronen Kommunikation genauso aus wie in der asynchronen. Wenn alle während der üblichen Bürostunden an ihren Rechnern sitzen – im Institut oder im Home Office – ist der Austausch über Mattermost wesentlich schneller und präziser als per Mail. Da es oft um Texte, Formeln, Codeschnipsel und Links auf Dateiablageorte geht, ergänzt Mattermost das persönliche Gespräch sinnvoll. Aber auch in der Zusammenarbeit mit studentischen Hilfkräften und Tutor_innen leistet Mattermost gute Dienste. Sie können an ihren oft wechselnden Arbeitstagen die vergangene Kommunikation im Projekt nachvollziehen und sich schnell wieder auf den Stand bringen.

Mattermost in der Lehre

2017 hat Axel Dürkop Mattermost erstmals in der asynchronen Betreuung von Studierenden eingesetzt und damit bisher ganz gute Erfolge gehabt. Die Herausforderungen liegen dabei nicht in der Benutzung des Tools. Vielmehr ist die Frage zunächst, wie Mattermost so attraktiv gemacht werden kann, dass es an die Stelle von WhatsApp tritt, das Studierende bisher sehr häufig für den Austausch innerhalb ihrer Kohorten einsetzen. Das Argument ist stets, dass wenn sie auf die Unterstützung von Axel Dürkop als Dozent Wert legen, sie sich über Mattermost an ihn wenden müssen. Wenn er eine Mail bekommt, bittet er darum, die Frage oder das Anliegen noch einmal in Mattermost zu formulieren – außer, es handelt sich um persönliche Angelegenheiten. Oft bekommt er dann eine Direktnachricht, die er gern beantwortet. Gleichzeitig werden die Studierenden gefragt, ob sie sich nicht vorstellen können, ihre Anfrage auch in einem öffentlichen Kanal zu stellen. Manchmal ergeben sich daraus dann erweitere Diskussionen mit anderen Studierenden.

Eine weitere Herausforderung liegt darin, dass die Studierenden über die Woche zu sehr unterschiedlichen Zeiten an ihren Rechnern sitzen und die gestellten Aufgaben erledigen. Damit Tutor*in und Lehrende*r dann auch online sind, wurden die Projektteams im vergangenen Semester gebeten, ihre TOBOT (Time Of Being Online Together) bestimmen lassen. Wir haben dann versucht, auch zu diesen Zeiten online zu sein, um uns möglichst zeitnah in die verhandelten Probleme und Fragestellungen einmischen zu können – wenn diese transparent in öffentlichen Kanälen waren. Die Idee halten wir nach wie vor für sinnvoll, allerdings konnte diese lose Form der Verabredung aus unterschiedlichen Gründen nicht immer eingehalten werden.

Zwischenfazit

Mattermost in Forschung, Lehre und Softwareentwicklung birgt großes Potenzial. Am wichtigsten scheint – wie immer bei Prozessen, die einen Kulturwandel bedeuten – Geduld zu haben und nicht zu früh aufzugeben. Gegenüber meinen Kolleg_innen und Studierenden wurde immer deutlich gemacht, dass es darum geht, etwas auszuprobieren und dann gemeinsam zu schauen, ob dabei was Sinnvolles herauskommt. Und dies scheint im Rückblick nicht unwesentlich bei der Einführung der neuen Software zu sein: Alle Beteiligten als gleichberechtigte Mitwirkende in einem Experiment zu behandeln, deren Gewohnheiten, Erwartungen und Bedürfnisse ernst genommen werden müssen, wenn das Projekt gelingen soll.

Referenzen

Der Digitale Freischwimmer ist ein Online-Angebot der TUHH. Er richtet sich in erster Linie an Hochschullehrende, die neugierig auf mediengestützte Lehr- und Lernszenarien sind.

Die Idee einer Website zu digitalen Medien ist dabei nicht neu. Es gibt sehr gute Angebote anderer Hochschulen und Institutionen, z.B. e-teaching.org oder das Wiki des Zentrums für multimediales Lehren und Lernen der Universität Halle. Diese Websites bieten über verschiedene Zugangswege sehr umfassende und detaillierte Informationen zu mediengestützten Lehrszenarien.

Der Digitale Freischwimmer hingegen bietet eine erste Orientierung für Lehrende, die zwar ExpertInnen ihrer Disziplin sind, mit digitalen Lehr- und Lernszenarien jedoch nur wenig vertraut sind. Insbesondere für MINT-Fächer bietet der Freischwimmer Impulse und zeigt Einsatzmöglichkeiten von digitalen Werkzeugen in der Lehre.

Wie ist die Idee zum Freischwimmer enstanden?

Fangen wir einmal von vorne an: Am Anfang des Freischwimmers stand die Broschüre Die gesamte Bandbreite nutzen. Mit digitalen Medien in MINT-Fächern lernen, die das Zentrum für Lehre und Lernen (ZLL) 2017 publiziert hat. Hierin sind Lehrszenarien und Erfahrungsberichte kurz und prägnant beschrieben.

Eine solche Print-Publikation ist eine tolle Sache und fand deutschlandweit unter MINT-Lehrenden und in didaktischen Zentren Anklang. Damit aber den immer neuen und aktuellen Tools Rechnung getragen werden kann, entschieden wir uns zu einer Online-Variante. Diese wird regelmäßig aktualisiert und berichtet über neue Trends und ihre Umsetzung in Lehrkontexten.

Der Digitale Freischwimmer soll mehr sein als ein Seepferdchen, aber eben kein Gold-Abzeichen. Stattdessen möchten wir Lust darauf machen, in die Möglichkeiten des digitalen Lehrens und Lernens hinein zu tauchen und erste Konzepte sicher umzusetzen, ohne im Meer der digitalen Möglichkeiten unterzugehen.

Was war uns bei der Konzeption des Freischwimmers wichtig?

Wir wollten auf keinen Fall eine endlose Sammlung von kompliziert klingenden Tools und Werkzeugen erstellen, sondern von den didaktischen Beweggründen Lehrender auszugehen. „Welche Zielsetzung haben Lehrende bei ihrer Veranstaltungsplanung im Kopf, und welche Rolle können digitale Medien hierbei spielen?” Dafür wählten wir folgende Kategorien aus: Gruppenarbeit gestalten, Studierende aktivieren, Prüfen & Feedback geben oder Schreibprozesse begleiten.

Auch taucht oft die Frage auf, wie sich mediengestützte Szenarien sinnvoll in die gesamte Veranstaltungsstruktur integrieren lassen. Um solchen Gesamtszenarien auf den Grund zu gehen, bietet der Freischwimmer die Kategorie „Didaktische Gesamtszenarien”.

Ein Thema ist hier beispielsweise das Konzept des Flipped Classroom: Was ist das? – dazu gibt ein kurzes Video Auskunft. Des Weiteren beschreiben wir welche Aspekte es zu beachten gilt, auf welche Stolpersteine man stoßen kann und natürlich: Wer hat an der TUHH schon „geflippt”? Der Freischwimmer hat also die Absicht, in einer leicht zugänglichen und praxisrelevanten Form zu berichten. Die Kategorie „Rechtliche und didaktische Grundlagen” deckt überdies Meta-Themen wie urheberrechtliche Fragen, OER und Lernziele ab.

Flipping the Classroom: Explained (2012). MediaCore. Link: https://www.youtube.com/watch?v=iQWvc6qhTds

Wie geht’s weiter?

In der Pressemitteilung der TUHH zum Freischwimmer hieß es: „Abzeichen schon gemacht?” Und tatsächlich haben uns schon viele gefragt, ob man beim Freischwimmer auch ein Zertifikat erwerben kann. In der Tat war so etwas wie ein Online-Lernmodul mit Badges von Anfang an mitgedacht. Der Digitale Freischwimmer ist also quasi gerade erst vom Startblock gesprungen. Es gilt noch einige Bahnen zu schwimmen.

In jedem Fall freuen wir uns über Feedback, Fragen, Ergänzungen und Wünsche zu unserem Online-Angebot.

Im letzten Artikel Jupyter Notebook und JupyterLab wurde vorgestellt, wie Forschende das Programm Jupyter Notebooks nutzen können, um eigene Ergebnisse für andere nachvollziehbar festzuhalten. Wir am Institut für Maritime Logistik haben uns gemeinsam mit dem Fraunhofer-Center für Maritime Logistik und Dienstleistungen (CML) im Rahmen vom Projekt MaLiTuP (Maschinelles Lernen in Theorie und Praxis, gefördert vom BMBF) damit beschäftigt, wie man dieses Werkzeug schon den Studierenden näherbringen kann. Dieser Artikel stellt nun die Nutzung von Jupyter Notebook und JupyterHub in der Lehre vor.

Wieso sind Jupyter Notebooks gewählt worden?

Im Bereich der Logistik fallen verschiedenste Arten von Daten an, darunter zeitbehaftete Daten, raumzeitliche Daten sowie Bilder. Zeitbehaftete Daten sind beispielsweise die Ankunftsraten von Lkw an einen logistischen Knoten, während die Bewegungsdaten eines Schiffs oder eines Lkw dann raumzeitliche Daten darstellen. Bilddaten sind u. a. Aufnahmen von Dashcams zur automatischen Identifikation von Straßenschildern. Diese Daten wollen wir in der Lehrveranstaltung gemeinsam mit den Studierenden untersuchen. Aufgrund dieser Vielfalt eignen sich jedoch viele Programme mit klassischen grafischen Oberflächen nicht. Bei Jupyter Notebooks hingegen stellt dies kein Problem dar, weil es eine große Auswahl von bewährten Bibliotheken gibt, wie z. B. pandas für zeitbehaftete Daten, folium für das Darstellen von raumzeitlichen Daten oder scikit-learn für das maschinelle Lernen.

Alles hat seinen Preis: Die Studierenden mussten zunächst lernen, wie man Datenauswertungen in Form eines Skripts formuliert. Um die Einstiegshürde niedrig zu halten, wurden ihnen Teile des Jupyter Notebooks bereits gestellt. Der Schwerpunkt lag darauf, konzeptuell passend Lücken auszufüllen und Code-Teile umzustellen.

Vorlesungsbegleitend haben wir Übungen angeboten. Dafür ist auf den Pool-Rechnern Anaconda für Python 3.6 installiert worden. Da die Studierenden auch gerne zu Hause arbeiten, war Anaconda auch sehr schnell auf eigenen Laptops installiert. Dies hat je nach Laptop-Modell manchmal länger gedauert. Insgesamt haben die Studierenden schnell gelernt, wie man mit den Jupyter Notebooks Daten einliest, visualisiert und wie man aus diesen Daten einen wissenschaftlichen und wirtschaftlichen Mehrwert generieren kann. Die Vorlesung dagegen diente als Raum, um im Voraus Begriffe und Konzepte zu vermitteln und manche Erkenntnisse aus der Forschung zu diskutieren.

Warum nun JupyterHub einsetzen?

Eine der großen Herausforderungen von Lehrenden ist es, den Studierenden ein “rundes” Modul anzubieten. Dazu gehört, dass zu den erwünschten Lernergebnissen die passenden Lehr- und Lernmethoden ausgewählt werden. Erfahrungsgemäß werden hauptsächlich Inhalte, die abgeprüft werden, auch von den Studierenden gelernt. Daher sollte die Prüfung auch zu den gewünschten Lernergebnissen und den Lehr- und Lernmethoden passen. Hierbei spricht man auch von Constructive Alignment.

Uns war wichtig, dass die Lernerfolge mit Jupyter Notebook einen Teil der Modulnote ausmachen, um das Engangement in der Übung zu honorieren. Deswegen haben wir uns schon früh entschlossen, eine teilweise computergestützte Prüfung durchzuführen. Dies bedeutet, dass ein Teil der Klausur klassisch auf dem Papier und ein weiterer Teil am Laptop erledigt wird. Die Abgabe der Ergebnisse erfolgte somit zum Teil digital.

Erste Gespräche mit dem Rechenzentrum haben gezeigt, dass es schwierig ist, auf jeden einzelnen Prüfungs-Laptop eine Anaconda-Version zu installieren. Aufgrund der technischen Struktur bot es sich an, dass jeder Laptop sich mit einer zentralen Instanz verbindet. Dort sollte dann ein Jupyter Notebook laufen. Für so einen Zweck ist der JupyterHub geeignet. Dieser lässt jeden Nutzer, der einen validen Login-Namen und ein dazu passendes Passwort über die Webseite eingibt, im Browser ein Jupyter Notebook öffnen. Über das Jupyter Notebook kann der Nutzer dann selbstgeschriebenen Code auf dem Server ausführen lassen. Die Jupyter Notebooks lassen sich auf dem Server dauerhaft abspeichern und zu einem späteren Punkt weiterbearbeiten. In unserem Fall enthält das Jupyter Notebook die Klausuraufgaben. Teil der Abgabe am Ende ist dann das bearbeitete Jupyter Notebook. Weil das Jupyter Notebook als Datei auf dem Server vorliegt, kann es beispielsweise vom Systemadministrator dann zentral gesichert werden. Im Anschluss müssen die Ergebnisse entsprechend archiviert werden.

Und ist das sicher?

Manch IT-affinen Personen mag beim eben genannten Absatz bereits der Sicherheitsaspekt ins Auge gesprungen sein. Wenn Studierende sich alle auf einer zentralen Instanz einloggen, können sie dann dort Informationen austauschen und so bei einer Klausur täuschen? Wie sieht es mit Spicken aus? Gibt es vielleicht mit den Laptops vielleicht ganz neue Möglichkeiten, wie man sich als Studierender während der Prüfung einen Vorteil sicher kann, der so nicht vom Prüfenden vorgesehen war? Hier sollte man sich früh mit abgesicherten Browsern, Firewall-Einstellungen, Containerisierung u. ä. auseinandersetzen. Ebenso kann man sich verschiedene Szenarien überlegen, wie ein Studierender betrügen könnte. In den meisten Fällen lässt sich durch eine aufmerksame Klausuraufsicht auch hier bereits viel abfangen. Es ist schließlich (bis auf die Laptops) eine ganz normale Klausur in Präsenz und einer begrenzten Bearbeitungszeit.

Für die Prüfung haben wir uns in diesen Fall dazu entschieden, die Studierenden über docker-Container voneinander zu isolieren. Dadurch wird das Kommunizieren zwischen den Studierenden erschwert und die Gefahr minimiert, dass sich Studierende gegenseitig stören können. Zur Nutzerverwaltung fiel die Wahl auf CouchDB, weil es leichtgewichtig ist und bereits eine Web-Oberfläche namens Fauxton mitbringt. Über diese Oberfläche können Benutzeraccounts erstellt und modifiziert werden. Es gibt hier einige Alternativen für Fortgeschrittene.

Wenn man im laufenden Betrieb schaut, wie viele docker-Container parallel arbeiten, sieht man die CouchDB, den JupyterHub-Container und für jeden der Studierenden jeweils einen weiteren Container, in dem das eigene Jupyter Notebook ausgeführt wird. Mit ein wenig Übung in docker (hierfür gibt es regelmäßig docker-Workshops an der TUHH) und Kommandozeilen-Kenntnissen in Linux kann man nun den JupyterHub zur Laufzeit überwachen.

Verlauf der Prüfung

Im August haben wir die Planung der computergestützten Prüfung anvisiert, die dann im Februar anstand. Diesen zeitlichen Rahmen haben wir auch gut ausgeschöpft, denn neben der Konfiguration vom JupyterHub haben wir uns ausführlich mit den rechtlichen Aspekten einer computergestützten Prüfung ebenso wie mit operativen Fragestellungen beschäftigt. Wird während der Prüfung der Server genügend Ressourcen haben? Was passiert, wenn der Server abstürzt? Wie sieht der Plan aus, wenn die Laptops ausfallen? Kurz vor der Prüfung gab es prompt ein automatisches Update einer Bibliothek, die daraufhin die Jupyter Notebooks abstürzen ließ. Dies ließ sich zum Glück schnell dadurch beheben, indem auf eine frühere Version des docker-Image zurückgegriffen wurde. Als dann die Prüfung durchgeführt wurde, beobachteten wir die Auslastung und das Verhalten des Systems sehr genau. Es lief dann technisch gesehen alles wie gewünscht. Das Zusammenspiel von JupyterHub, CouchDB und den selbstgeschriebenen Python-Skripten hat sich als funktionstüchtig bewiesen.

Die Benutzerverwaltung über Fauxton bzw. selbstgeschriebenen Python-Skripten ist bislang eher eine Behelfslösung. Es wäre schöner, wenn es eine fertige Anwendung gäbe, die die Prüfungs-Accounts des Rechenzentrums einlesen und dann verwalten könnte. Dies sollte natürlich mit einem geringen Wartungs- und Administrationsaufwand einher gehen, um computergestützte Prüfungen realisierbar zu halten.

Ebenso war das Verhalten des abgesicherten Browsers nicht so, wie es sich der eine oder die andere Studierende gewünscht hat: Es ließen sich keine zwei Browser-Fenster nebeneinander anordnen. Dies ist nämlich dann hilfreich, wenn man das Benutzerhandbuch für ein Modul nebenbei geöffnet haben möchte.

Für die Studierenden war es eine ungewohnte Situation, in der Prüfung mit dem Laptop zu arbeiten. Die Anspannung war groß und manches, was in der Übung noch einfach von der Hand ging, war nun während der Prüfung etwas herausfordernder. Im nächsten Jahr wird nun geplant, noch besser auf diesen Aspekt einzugehen, um eine passgenaue Prüfung anbieten zu können. Von Jupyter Notebook als ein wertvolles Werkzeug für spätere Projekte in ihrem Studium waren die Studierenden auf jeden Fall überzeugt.

Hands On! Einen eigenen JupyterHub starten!

Eine funktionierende Konfiguration eines JupyterHubs zum Ausprobieren ist auf dem TUHH-Gitlab verfügbar. Für den Einsatz in der Prüfung müssen noch einige Sicherheitseinstellungen vorgenommen sowie ein Konzept für die Archivierung der Testergebnisse erstellt werden. Gerne stehe ich dafür als erster Ansprechpartner zur Verfügung. Zum Kennenlernen und Weiter-Basteln genügt die mit ausgelieferte Konfiguration.

Für den ersten Einsatz benötigt man einen Linux-Rechner mit Python 3 und docker. Als erstes muss die Datei „.env” angelegt werden. Dafür kann man sich die Datei „.env.sample” kopieren und auf jeden Fall das Passwort anpassen. Über das Skript „start.sh” wird dann der JupyterHub gestartet. Sobald dies ausgeführt worden ist, ist unter die Login-Maske für die Jupyter Notebooks verfügbar. Als Test-Account ist der Nutzer „test” mit dem Passwort „test” bereits angelegt. Die visuelle Benutzerverwaltung ist über http://<>:5984/_utils/ erreichbar (wobei der Platzhalter durch die IP-Adresse oder Vergleichbares ausgetauscht werden muss). Die Login-Credentials aus der „.env“-Datei werden nun hier für den Login verwendet. Durch das Löschen und Anlegen von sogenannten Dokumenten in der Datenbank „users” können Accounts entfernt oder hinzugefügt werden. Hierbei kann man sich am Beispiel-Benutzer “test” mit dem Passwort “test” orientieren.

Danksagung

Vielen Dank ans Zentrum für Lernen und Lehre (ZLL), an das Rechenzentrum (RZ) und an das Institut für Technische Bildung und Hochschuldidaktik (ITBH) für die konsequente Unterstützung ebenso wie für die Kekse!

Update 04.06.2020

Unter https://www.tuhh.de/mls/lehre/e-pruefungen.html ist eine weitere Reflexion des Prüfungsansatzes zu finden.

Die preisgekrönte Software Jupyter Notebook ist in vielen Forschungsbereichen zum Defacto-Standard geworden. Bei der Entwicklung von Algorithmen, der Verarbeitung von Daten und der Zusammenarbeit in offenen Forschungsprozessen spielt die Software ihre Stärken aus. JupyterLab ist die Weiterentwicklung von Jupyter Notebook und bietet vor allem auf der Benutzeroberfläche einige sinnvolle Neuerungen (vgl. Abb. 1).

Loslegen mit Jupyter

Die klassische Arbeit in Jupyter Notebooks beginnt mit dem Import von Daten. Mit zahlreichen Skript- und Programmiersprachen können diese aufbereitet, analysiert und visualisiert werden. Unter den verfügbaren Kerneln befindet sich auch eins für Matlab, das in den Ingenieurwissenschaften nach wie vor stark verbreitet ist.

Da Jupyter Notebook mit so genannten Zellen arbeitet, können sich Codezellen und Textzellen abwechseln. Code wird direkt in den Zellen ausgeführt, Texte werden in Markdown verfasst. Dadurch können Hypothesen und Annahmen über die Daten formuliert und anschließend mithilfe von Code direkt überprüft werden. Die folgende Zelle hält dann die Beobachtung und Interpretation fest. So entstehen reproduzierbare Forschungstagebücher und im fortgeschrittenen Stadium publikationsreife Artikel. Abb. 2 zeigt an einem einfachen Beispiel die Verzahnung von Text und Code.

Was Burger und Notebooks gemeinsam haben

Die Jupytertools haben deshalb in vielen verschiedenen Domänen einen bedeutenden Stellenwert erlangt, weil sie den klassischen wissenschaftlichen Workflow so komprimiert abbilden wie ein Burger ein Dreigängemenü:

• Salat und Brot als Vorspeise
• Fleisch im Hauptgang und
• Käse zum Abschluss

Für Jupyter Notebook heißt das:

• Analysieren und erkennen
• Schreiben
• Publizieren

Wie auch der Hamburger die Abfolge der drei Gänge zeitlich und räumlich in sich vereint, finden auch in einem Notebook die drei Schritte des wissenschaftlichen Arbeitens zeitgleich und iterativ statt: Während ich forsche, schreibe ich auf, was ich beobachte, forsche mit neuen Erkenntnissen weiter, schreibe und schreibe und veröffentliche im besten Sinne von Open Science schon während des Forschungsprozesses meine Mitschriften und Daten.

Mein Forschungsergebnis veröffentliche ich dann am besten in einem Open-Access-Journal und zitiere darin den Digital Object Identifier (DOI), unter dem meine Notebooks zu finden sind. Den DOI habe ich von Zenodo bekommen, als ich dem Dienst einen Link zu meinem GitHub-Repo mit meinen Jupyter Notebooks gezeigt habe.¹ Der Journalartikel zusammen mit meinen Notebooks und Daten machen mein Forschungsergebnis und das Vorgehen transparent und nachvollziehbar.

Um es anderen Wissenschaftler_innen noch einfacher zu machen, nutze ich Tools wie binder, die es erlauben, Notebooks aus dem Git[Hub|Lab]-Repo direkt im Browser interaktiv nachzuvollziehen, um damit die Ergebnisse aus der Publikation zu reproduzieren und zu prüfen. Abb. 3 visualisiert diesen möglichen Workflow exemplarisch.

Über den folgenden Button

kann das Beispiel aus Abb. 2 direkt im Browser nachvollzogen werden. In der sich öffnenden Ansicht ist die Datei jupyter-beispiel.ipynb anzuklicken. Anschließend können die Zellen geändert und mit STRG+ENTER erneut ausgeführt werden.

Jupyter Notebook und JupyterLab laufen auf allen relevanten Betriebssystemen als Browsertool und können bspw. mithilfe von Anaconda auf dem eigenen Rechner installiert werden. Über eine serverseitige Installation von JupyterHub sind auch kollaborative Arbeiten an Daten- und Forschungsprojekten möglich.

Jupyter-Notebook-Installationen sind einfach über Plugins zu erweitern. So können z.B. mit RISE Präsentationen direkt aus Notebooks erstellt werden. Jede Zelle kann dabei zu einer eigenen Folie werden, in der der Code bei einer Präsentation live ausgeführt werden kann!

Jupyter an der TUHH

Die TUHH verfügt seit 2018 über einen JupyterHub, der im WiSe 2018/19 erstmals auch für elektronische Prüfungen eingesetzt wird. Zuvor hatten die Studierenden ein Semester lang eine handlungsorientierte Einführung in Machine-Learning-Grundlagen mit Python, wobei Jupyter Notebooks das zentrale Tool waren. Wir werden in diesem Blog noch ausführlich darüber berichten.

Weiterführende Links

Docker ist eine moderne Form, Softwareanwendungen in virtuellen Containern auszuführen. Die Vorteile dieser Technik sind so zahlreich, dass Docker die IT-Welt im Sturm erobert hat (vgl. Vaughan-Nichols, 2018) und seit 2016 auch die TUHH.

Die Geschichte von Docker an der TUHH beginnt mit der Hamburg Open Online University (HOOU). Mittelfristiges Ziel des Großprojektes war es 2016, eine Lernplattform zu entwickeln, auf der die Lernarrangements der sechs staatlichen Hochschulen Hamburgs zum Mitmachen bereitgestellt werden sollten. Bis zur Fertigstellung der Plattform war jede Hochschule aufgefordert, die Ideen der Lehrenden “mit Bordmitteln” umzusetzen, mit vorhandenen Tools und aus der bisherigen Erfahrung mit E-Learning-Angeboten heraus. Die TUHH hat diesen Moment genutzt, um in ihrem wachsenden digitalen Experimentierfeld einige neue Technologien und Praktiken zu erproben und in den Kontext von Forschung und Lehre zu transferieren.

Die Motivation, Docker zu nutzen, entsprang zunächst einer praktischen Analyse der Software Sandstorm. Diese einzusetzen erschien aus zweierlei Gründen als technische Basis für die HOOU an der TUHH sinnvoll:

• Sandstorm ist freie Software und kann in Hochschulrechenzentren installiert werden.
• Sandstorm virtualisiert die verschiedenen Applikationen intern, erfordert also keinen dedizierten Rechner pro Anwendung.
• Sandstorm integriert eine Vielzahl von so genannten Web-2.0-Tools, die Anwender_innen unter einer einzigen Anmeldung zusammenziehen können.

Gerade aus dem dritten Grund schien Sandstorm bestens geeignet, die Grundlage für individuelle webgestützte Lernarrangements zu stellen. An der TUHH setzten wir Sandstorm in einer Entwicklungsumgebung auf und teilten unsere gewonnenen Erfahrungen mit den Kolleg_innen aus dem HOOU-Team. Begrüßt wurde die Übersicht der verschiedenen Typen von Anwendungen, die es als freie und quelloffene Software gab. Das Potenzial wurde auch darin gesehen, dass der App Market von Sandstorm und die einfache Inbetriebnahme der Applikationen vielen Lehrenden helfen würde, neue Anwendungen und Anwendungstypen kennenzulernen und auf neue und individuelle Ideen für ihre Lernarrangements zu kommen (vgl. Abb. 1).

Aus der Perspektive der Administration und Wartung allerdings erschien uns Sandstorm zu sehr als Blackbox, deren Innenleben wir nicht wirklich kontrollieren konnten. Auch war das technische Konzept der “Verpackung” von Anwendungen für Sandstorm, die Virtualisierung über Vagrant, zu umständlich, um die Entwicklungsgeschwindigkeit und Anpassbarkeit zu erreichen, die uns vorschwebte. Zudem war nicht klar, ob das Geschäftsmodell von Sandstorm langfristig tragen würde (vgl. Abschnitt “Chancen und Herausforderungen von Docker”). Sandstorm hatte uns inspiriert, aber nicht zufriedengestellt.

Der Einfluss von Software auf unsere Lebens- und Arbeitswelt wird immer deutlicher wahrnehmbar und verstärkt sich zusehends. So besteht bspw. das Internet, wie wir es heute in Form des World Wide Web hauptsächlich verwenden, nicht mehr nur aus statischen Webseiten, sondern aus komplexen Applikationen wie Shops oder sozialen Netzwerken. Auf unseren Mobiltelefonen befinden sich Apps, mit denen wir ständig interagieren und Daten austauschen, technische Geräte wie Waschmaschinen, Autos, Fahrkartenautomaten und Fernseher funktionieren nicht mehr ohne Software.

Software entsteht in interdisziplinärer Teamarbeit

U.a. aus diesem Grund ist eine oft gehörte Forderung dieser Tage, dass Menschen früh das Programmieren lernen sollten, um später in der Arbeitswelt bestehen zu können und besser zu verstehen, wie die Welt um uns herum funktioniert. Auch wenn diese Forderung vielleicht berechtigt ist und Grundkenntnisse der Softwareentwicklung in digitalen Zeiten nicht schaden können, liegt der eigentliche Kern der Sache woanders: Moderne Softwareanwendungen bestehen nicht nur aus dem Quellcode, der sie antreibt. Sie enthalten Informationen in Form von (bewegten) Bildern, Tönen, Texten und Daten, die erstellt und in die Anwendung integriert werden müssen. Häufig müssen die Anwendungen auch noch in zahlreiche weitere Sprachen übersetzt werden. Diese Aufgaben verteilen sich im Entwicklungsprozess von Software in der Regel auf ganz unterschiedliche Personen, Berufe und Professionen, und am Ende kommt ein multimediales digitales Produkt heraus, das durch Programmcode zusammengehalten wird und seine interne Logik und Funktionsweise erhält.

Was in diesem Sinne für Software gilt, ist auch auf digitale Medien allgemein übertragbar. Bücher sind heute zunächst immer digital vorhanden, auch wenn sie in einem letzten Schritt auf Papier gedruckt werden. Lehr-/Lernmaterialien in Form von PDF-Dokumenten, Webseiten oder Infografiken entstehen in der Regel durch Viele, die gemeinsam an einem Produkt arbeiten und ihren professionellen Teil dazu beitragen. Für eine technische Hochschule ist es daher nicht nur wichtig, das Programmieren zu lehren. Es ist heute ebenso wichtig, mit den Tools und Workflows vertraut zu machen, die Kollaboration und Teamarbeit an digitalen Artefakten erst ermöglichen. Software – und damit auch die Welt, in der wir in Zukunft leben werden – entsteht in interdisziplinärer Teamarbeit.

Daher sei an dieser Stelle die These gewagt, dass nicht jede und jeder unbedingt programmieren können muss. Wichtiger ist die Kenntnis von Kollaborationstools und -workflows, da sie auch nichtprogrammierende Menschen in die Lage versetzt, die digitale Zukunft mitzugestalten und sich aus seiner Profession heraus an digitalen Projekten beteiligen zu können. An der TUHH ebnen wir mit einer hauseigenen weltöffentlichen GitLab-Instanz dieser Kompetenzförderung den Weg.

Von der Open-Source-Bewegung lernen

GitLab ist eine Software zur dezentralen Zusammenarbeit an textbasierten digitalen Artefakten. Das bedeutet, dass Menschen weltweit verteilt, aber dennoch gemeinsam an Software, Webseiten, Texten und Datensammlungen arbeiten können. Sie müssen sich dazu nicht einmal persönlich kennen oder sehen und können doch Großes vereint zustande bringen. Diese Form der Kollaboration ist aus der Open-Source-Bewegung entstanden und erhielt 2005 neuen Schwung durch die Veröffentlichung von Git, einem Tool zur Verwaltung von Zwischenständen im Entwicklungsprozess von Software. Zu dieser Zeit war der Kollaborationsaspekt von Git noch nicht sehr ausgereift. Als 2008 das amerikanische Unternehmen GitHub mit seiner gleichnamigen Webplattform zum gemeinsamen Arbeiten an Code auf den Markt trat, veränderte sich die Entwicklungskultur der Open-Source-Gemeinschaft entscheidend: Durch den Mechanismus des Forkens ist es nicht mehr wie zuvor nötig, das Vertrauen einer Projektcommunity zu gewinnen, um Code beisteuern zu dürfen. Man fertigt nun online eine Kopie des Quellcodes an, verbessert ihn und stellt dann einen pull request an die Urheber_innen, mit dem diese aufgefordert werden, den Beitrag zu integrieren. Diesem Feature der Plattform ist es zuzuschreiben, dass sich die Entwicklung großer und kleiner Softwareprojekte im Open-Source-Umfeld rasant beschleunigte.

Die TUHH hostet eine eigene GitLab-Instanz

Für eine Hochschule stellt sich die Frage, ob die systematische Förderung von Kollaboration und Teamarbeit auf der proprietären Plattform GitHub im amerikanischen Rechtsraum strategisch klug ist. Rechtliche Aspekte in verschiedener Hinsicht sowie die Abhängigkeit von sich wandelnden Geschäftsmodellen im Startup-Sektor legen nahe, Alternativen im Bereich freier und quelloffener Software zu suchen. Aus diesen Gründen hat sich die TUHH entschieden, Kollaboration und Teamarbeit im skizzierten Sinne mit GitLab zu betreiben und aktiv zu fördern.

Seit dem 17. November 2016 hostet das Rechenzentrum der TUHH eine eigene GitLab-Instanz in der Community Edition. Der Prozess bis dahin ist eng verwoben mit dem HOOU-Projekt an der TUHH, in dem wir mit GitLab die ganzheitliche Entwicklung von Open Educational Resources (OER) implementiert haben. Am Prozess der Einrichtung und Bereitstellung des Dienstes waren und sind viele Akteur_innen der TUHH beteiligt, die gemeinsam daran arbeiteten, den Dienst weltöffentlich für alle Interessierten online zu stellen. Nichts Geringeres als interdisziplinäre und internationale Forschungs- und Lehrkooperationen sind das Ziel des öffentlichen GitLabs der TUHH. GitLab ist für viele Institute der Hochschule zu einem zentralen Werkzeug der Zusammenarbeit geworden, wir zählen bis heute über 1000 registrierte Nutzer_innen und entwickeln fortlaufend neue Ideen zum Einsatz in Forschung, Lehre und Projektmanagement.

Der Prozess bringt Akteur_innen näher zusammen

Darüber hinausgehend hat der Prozess der Einrichtung von GitLab viele Angehörige der TUHH in der Diskussion über die Digitalisierungsstrategie der Hochschule näher zusammengebracht. U.a. wurde die Arbeitsgruppe openTUHH gegründet, in der sich die Diskurse Open Education, Open Science und Open Access bündeln. Sie werden von verschiedenen Instituten, der TUHH-Bibliothek, dem Rechenzentrum und dem Präsidium verfolgt und gestaltet. Die Zusammenarbeit mit dem Datenschutzbeauftragten der TUHH hat dazu geführt, den Dienst von Anfang an sicher im Angebot der Hochschule zu verankern und alle Akteur_innen für die Anforderungen an Sicherheit, Datenschutz und verschiedene rechtliche Aspekte zu sensibilisieren. Schließlich hat sich eine monatliche Arbeitsgruppe zu GitLab herausgebildet, in der die Wünsche und Anforderungen der Nutzer_innen reflektiert werden, um die Nutzungsmöglichkeiten entsprechend anzupassen.

Zusammenfassung

Zu diesem Zeitpunkt können wir festhalten, dass GitLab mit seinen vielen technischen Möglichkeiten zahlreiche Nutzer_innen an der TUHH begeistert. Zudem zeigt der Prozess der Einrichtung und Bereitstellung, welche positiven Effekte sich auf verschiedenen Ebenen innerhalb der eigenen Hochschule ergeben können. In den zahlreichen Projekten, die wir bisher mit GitLab durchgeführt haben, haben sich Menschen mit unterschiedlichen Hintergründen, Erfahrungen und Kenntnissen produktive Teams gebildet, die gemeinsam freie Software und offene Bildungsressourcen entwickeln können.

Weitere Artikel zum Thema in diesem Blog

GitLab kam bisher in einer Reihe verschiedener Projekte zum Einsatz, die in den folgenden Beiträgen weiter ausgeführt werden:

• GitLab als CMS einsetzen

Weiterführende Links und Literatur

• Entwicklung einer offenen technischen Infrastruktur für HOOU-Lernarrangements an der TUHH im Blog der HOOU, 28.04.2016
• Ein technisches System für die kollaborative OER-Entwicklung im Experimentierfeld der TUHH im Blog der HOOU, 01.06.2017
• Bell, P. (2015). Introducing Github: A Non-Technical Guide. Sebastopol, CA: O’Reilly Media Inc.
• Hogbin Westby, E. J. (2015). Git for Teams. Sebastopol: O’Reilly.

Das Projekt RUVIVAL beschäftigt sich mit Maßnahmen zur Regenerierung degradierter Regionen. Dabei werden in einem internationalen Team verschiedene Lehr- und Lernmaterialien, sowie Veröffentlichungen in Buch- und Schriftenreihen erstellt. Diese Materialien sind auf www.ruvival.de aufrufbar, zudem wird dort ein Simulationsspiel angeboten.

Als Projektplanungstool und Plattform für das Simulationsspiel wird Hum Hub genutzt. HumHub ist eine freie Social Networking Software und bietet durch seine Flexibilität viele Möglichkeiten der Anwendung für RUVIVAL. Dabei werden zwei HumHub Installationen verwendet, die auf dem Server vom Rechenzentrum der Technischen Universität Hamburg (TUHH) gehostet werden.

Nutzung von HumHub für die Teamkommunikation

HumHub wird unter anderem für die Organisation und Kommunikation bei der Erstellung von Open Educational Resources (OER) durch Studierende genutzt. Der Schaffungsprozess der OER wird von MitarbeiterInnen und DoktorandInnen des Institutes für Abwasserwirtschaft und Gewässerschutz (AWW) betreut. Dies erfolgt durch persönliche Gespräche, der Hauptteil der Kommunikation findet jedoch auf der HumHub Anwendung statt. Dort laden Studierende erste Versionen ihrer Materialien hoch, die über die Kommentarfunktion auf der Plattform diskutiert werden können.

HumHub bietet zudem die Möglichkeit Erweiterungen zu nutzen, sogenannte Module (z.B. Kalender, Umfragen, To-Do Listen,…). Diese finden bei RUVIVAL viele Anwendungen und erleichtern die Organisation des Projektes und den Informationsfluss. Um den Prozess der OER Erstellung zu unterstützen, gibt es beispielsweise eine Liste mit Links zu Webseiten auf denen Materialien mit Creative Commons Lizenz gefunden werden können (siehe Abbildung 1). Diese Liste ist durch alle Projektteilnehmenden erweiterbar und jeder Link kann kommentiert werden.