Wie wir uns mit dem Chat-Tool Mattermost über gescheiterte Software-Builds informieren lassen, den Speiseplan der HCU-Mensa einsehen und den Platz an unserem Kicker reservieren.
Für viele Teams stellt sich irgendwann die Frage, welche Chat-Lösung sie verwenden wollen. Bei subshell haben wir uns für Mattermost entschieden. Das Backend von Mattermost ist in Go geschrieben und verwendet eine MySQL-Datenbank, das Frontend nutzt Javascript und React.
Mit dem webbasierten Client können wir auf die Chat-Nachrichten von überall zugreifen. Außerdem ist das System open source und läuft mit all seinen sensiblen Daten in unserem eigenen Netzwerk.
Bald nach Einführung fragten wir uns jedoch, wie wir unsere tägliche Arbeit besser in Mattermost integrieren können – zum Beispiel den Austausch über unsere Sophora-Builds.
Also haben wir den Build-Server Jenkins so konfiguriert, dass er dem zuständigen Team über Mattermost Bescheid gibt, wenn ein Build-Job gescheitert ist.
Entscheidend waren hierfür das Mattermost-Plugin für Jenkins und die Konfiguration sogenannter Incoming-Webhooks. Erst dann stellt Mattermost Endpunkte zur Verfügung, die andere Systeme per HTTP ansprechen können.
Das Plugin im Jenkins nutzt diese Endpunkte schließlich, um Nachrichten zu versenden.
Diese einfache und komfortable Erweiterung hat uns motiviert, weitere Aspekte unseres Arbeitsalltags in Mattermost zu integrieren – eines davon im Rahmen unserer regelmäßigen Labdays.
Als regelmäßige Besucher und Besucherinnen der nahgelegenen HCU-Mensa waren wir es satt, die Menü-Übersicht umständlich im Browser aufzurufen.
Stattdessen haben wir eine kleine Spring-Boot-Anwendung namens Mensa-Bot geschrieben, die den Speiseplan täglich um 11 Uhr aus dem HTML der Uni-Seite herausliest und per Incoming-Webhook als Markdown-Tabelle in einen der subshell-Channels sendet.
Außerdem benutzt unser Mensa-Bot die Slash-Commands von Mattermost.
Mit ihnen kann Mattermost – bei einer eingehenden Nachricht (beginnend mit einem Slash) – eine Anfrage an einen konfigurierbaren HTTP-Endpunkt versenden, der direkt der Benutzerin oder dem Benutzer antwortet.
Unseren Bot kann man jetzt fragen, was heute oder morgen auf dem Speiseplan steht ("/mensabot heute" oder "/mensabot morgen") oder was sich hinter welcher Abkürzung bei den Zusatzstoffen verbirgt ("/mensabot zusatzstoff 10").
Danach wollten wir mit Mattermost ein weiteres Problem lösen: den komplizierten Zugang zu unserem Kicker.
Viele Kolleginnen und Kollegen hatten keine Lust mehr, den relativ weiten Weg zum Kicker auf sich zu nehmen, nur um dann festzustellen, dass dieser schon belegt ist. Doch wie findet man heraus, ob der Kicker-Tisch frei ist oder nicht?
Da unser Kicker in einem fensterlosen Raum steht, muss man zum Spielen das Licht anschalten.
Also haben wir einen Raspberry Pi mit einem Lichtsensor ausgestattet. Eine Spring-Boot-Anwendung namens Kicker-Bot fragt den Lichtsensor mit der Bibliothek Pi4j ab und stellt so fest, ob im Raum das Licht an oder aus ist.
In Mattermost kann man dann über ein Slash-Command fragen, ob der Kicker belegt ist ("/kicker frei") oder sich und andere Benutzer für ein Spiel anmelden ("/kicker bescheid @user1 @user2 ...").
Durch die Anmeldung kommt man in eine Warteschlange und wird per Incoming-Webhook direkt vom Kicker-Bot in Mattermost direkt angeschrieben, wenn der Kicker wieder frei ist – d.h., wenn das Licht wieder aus ist.
Spring-Boot macht die Wartung des Bot möglichst komfortabel, da sich die kompilierte Anwendung wie ein init.d-Service verhält. Dieses haben wir so konfiguriert, dass unser Kicker-Bot bei jedem Start des Raspberry Pis gleich mit gestartet wird.
Unser Abenteuer mit Mattermost ist damit aber noch längst nicht zu Ende. Aktuell schauen wir uns die HTTP-API von Mattermost an. Und vielleicht kann man zukünftig auch die gemeinsamen Pizzabestellungen noch besser organisieren ...
