dev.ebroda.de

Blitzfotos im Gewittervideo finden

Eike Broda — Fri, 04 Jun 2021 23:13:00 +0000

Gerade sah der Himmel sehr interessant aus. Des öfteren waren leichte Blitze zu sehen. Also die Spiegelreflex rausgeholt und ein Video vom Himmel gemacht. Mit dem Plan da später dann mal nach Fotos von Blitzen am Himmel zu gucken. Das ganze habe ich dann wenig später auch umgesetzt. Also erstmal das Video in viele Einzelbilder konvertieren. Dabei hilft ffmpeg, die Wunderwaffe für alles, was um Video geht. Einfach mal ffmpeg + (englische Beschreibung, was ihr machen wollt) googlen und sicherlich gibt es bei StackOverflow einen entsprechenden Post dazu. In dem Fall führte dann diese Antwort ans Ziel und hatte auch noch den netten Tipp, das doch besser mit JPGs zu machen. Okay, dann also mal los. Das Video kommt direkt von der SD-Karte:

ffmpeg -i /media/dev/nnnn-nnnn/DCIM/101CANON/MVI_1121.MP4 -vf fps=30 -qscale:v 2 out%d.jpg

Okay, nun haben wir einen Ordner voll mit jpg-Bildern. Die kann man jetzt in einem Bildbetrachter, z.B. eog, durchschauen und dann den Blitz suchen. Ein guter Viewer schafft es zwar im Daumenkino-Modus, trotzdem muss man noch einiges an Fotos durchschauen. Bei 30 Frames, die die EOS macht, sind das bei 10 Minuten immerhin 60 * 30 * 10 = 18.000 Fotos. Das muss doch besser gehen. Und eine intuitive Idee war: Gucken wir doch mal, wie hell das Bild insgesamt ist. Durch den Blitz muss das doch heller werden. Und wieder StackOverflow und schon kann mittels Variante 4 die Helligkeit bestimmt werden. Dann mal ein Foto anschauen, wie hell das so im Mittel ist ohne Blitz und das mit ein bisschen Puffer als Grenzwert nehmen. Hier ist es die 16 geworden. Da einfach mal ein bisschen mit rumprobieren. Hängt stark von den Aufnahmen ab und wie hell insgesamt die Bilder sind. Zusätzlich noch etwas Logik um alle Dateien in einem Verzeichnis aufzulisten, fertig ist Variante 1 des Skripts. Die speichert dann auch alle gefundenen Bilder in einer Liste und gibt die am Ende leerzeichen-getrennt zurück, sodass alle interessanten Bilder einfach mittels cp oder mv in ein extra Verzeichnis verschoben werden können.

#! /usr/bin/python3
import math

from os import listdir
from os.path import isfile, join
from PIL import Image, ImageStat


def brightness(im_file):
   im = Image.open(im_file)
   stat = ImageStat.Stat(im)
   r,g,b = stat.rms
   return math.sqrt(0.241*(r**2) + 0.691*(g**2) + 0.068*(b**2))


if __name__ == '__main__':
  mypath = '.'
  onlyfiles = [f for f in listdir(mypath) if isfile(join(mypath, f)) and f[-3:] == 'jpg']

  files = []

  for f in sorted(onlyfiles):
  	bright = brightness(f)
  	if (bright > 16):
  		print(f, bright)
  		files.append(f)

  print("Found:")		
  print(" ".join(files))

Lässt man das Skript nun laufen und schaut mal in die Prozessorauslastung (htop), dann fällt auf, dass da irgendwie nur Prozessorkern was zu tun bekommt. Python läuft halt standardmäßig nur in einem Thread. Aber auch da lässt sich doch was machen. Also wieder Google angeschmissen und klar, Python hat ne Bibliothek dafür: multiprocessing und da gibt es dann auch ein entsprechendes Tutorial zu. Letztendlich kurz zusammengefasst: Die Aufgabe muss so runtergebrochen werden, dass sie in mehrere Teilaufgaben berechnet werden kann. Bei einer Liste an Dateien ist das natürlich relativ einfach, da bekommt jeder Prozessorkern einfach einen Teil der Liste. Bei n Kernen jeder dann eben aufgerundet 1/n. Damit hat der letzte Kern dann zwar etwas weniger zu tun, aber die Abweichung ist kleiner als n. Also bei 18.000 Fotos eher zu vernachlässigen. Der Rechner hat 8 Kerne, das macht also dann 18.000/8 = 2.250. Das geht hier sogar genau auf, somit hat jeder Kern 2.250 Bilder, die er sich anschauen soll.

Der erste Versuch, einfach eine Liste per Referenz an die working-Funktion zu übergeben, ist gescheitert. Die Liste war hinterher einfach leer. Aber auch dafür gibt es natürlich wieder eine Lösung und weniger später gibt es nun den kompletten Code, der alle Kerne auslastet:

#! /usr/bin/python3
import math
import sys
import multiprocessing
import os

from os import listdir
from os.path import isfile, join
from PIL import Image, ImageStat


def brightness(im_file):
    im = Image.open(im_file)
    stat = ImageStat.Stat(im)
    r,g,b = stat.rms
    return math.sqrt(0.241*(r**2) + 0.691*(g**2) + 0.068*(b**2))


def working(selected_files, files, start, end, i):
    if end > len(files):
        end = len(files)

    for f in files[start:end]:
        bright = brightness(f)
        if (bright > 16):
            print(f, bright)
            selected_files.append(f)


if __name__ == '__main__':
    mypath = '.'
    onlyfiles = [f for f in listdir(mypath) if isfile(join(mypath, f)) and f[-3:] == 'jpg']

    thefiles = sorted(onlyfiles)

    processes = []

    cores = os.cpu_count()
    part_work = math.ceil(len(thefiles)/cores)
    start = part_work

    manager = multiprocessing.Manager()
    selected_files = manager.list()

    for i in range(0, cores):
        end = start + part_work
        p = multiprocessing.Process(target=working, args=(selected_files, thefiles, start, end, i))
        processes.append(p)
        p.start()
        start = end

    for process in processes:
    	print(process.join())

    print("Done with all threads. Found ")
    print(" ".join(selected_files))
    print()

Und nun final noch das, worauf wir alle warten. Insgesamt ist es doch etwas enttäuschend, aber die Bilder rauschen leider alle sehr und es war auch ziemlich wolkig.

Erstaunlich auch, wie kurz die Blitze tatsächlich sind. Hier drei Frames, die direkt nacheinander kommen. Bei 30 FPS also je etwa ¹⁄₃₀ Sekunde = 33 ms auseinander:

Das Skript funktioniert natürlich auch mit Videomaterial, z.B. von YouTube. Schaut da einfach mal nach “Gewitter”, da gibt es auch einiges, z.B. das hier. Testweise habe ich da auch mal das Skript drübergeschickt und es hat die interessanten Bilder aussortiert. So, nun wird’s Zeit die Tabs zu schließen. Der Teil hier ist fertig :)

PS: Ist das schon Machine Learning? :)

Karten für Cards Against Humanity parsen

Eike Broda — Thu, 23 Apr 2020 23:30:00 +0000

Um das Sommerfest-Team auch während der Corona-Krise zusammenzuhalten, kam die Idee auf, im Web einige Spiele zu spielen. Eines der gewünschten Spiele war Cards Against Humanity (CaH). Von dem Spiel sind diverse Varianten im Internet zu finden, da das Ursprungsspiel unter CC-BY-NC-SA 2.0 Lizenz steht. Nach ein bisschen ausprobieren war mit Pixels Against Humanity auch eine gut funktionierende Variante gefunden. Das Deployen auf einem U7 war einfach und somit läuft nun eine eigene CaH-Instanz unter cah.wpaf.de.

Beim Ausprobieren mit Freunden hatten wir ein paar Probleme mit den englischen Karten, die den Spielspaß deutlich reduziert haben, da wir doch einiges nicht verstanden haben. Also kam die Idee auf, ob es nicht auch deutsche Karten gibt.

Erstmal wurde geguckt, wie die Karten denn überhaupt definiert werden. Diese Variante verwendet dafür recht einfach eine json-Datei, die beim Start des Servers eingelesen wird.

{
 'blackCards': [{"text": "I got 99 problems, but __ ain't one", "pick": 1}, ...],
 'whiteCards': ["Active Listening", ...],
 'Base': {
	'name': 'Base Set',
	'black': [0,...],
    'white': [0,...]
  }
}

Zuerst gibt es für jede Farbe eine Liste mit Karten. Dabei sind die schwarzen Karten jeweils ein Dict aus dem Text und der Anzahl an weißen Karten, die auf die schwarze Karte gespielt werden sollen. Bei den weißen Karten ist es einfacher, hier ist es einfach eine Liste. Anschließend wird ein Set aus diesen Karten generiert. Es kann mehrere Sets geben, die über den Key identifiziert werden (hier Base). Sets verfügen über einen Namen und referenzieren dann die weißen und schwarzen Karten über ihre Position in den entsprechenden Listen blackCards und whiteCards.

Also ging die Suche los und Nikolas hat recht fix eine deutsche Variante in LaTeX auf GitHub gefunden. Das Problem war nun: Wie bekommt man die Fragen aus den TeX-Sources raus? Da hilft ein Blick in die Sources (categories/basic.tex):

[...]
\titlecard{Basis}%
%
\whitecard{Basis}{Aktives Zuhören.}%
[...]
\blackcard{1}{Basis}{Ich habe 99 Probleme, \newline aber \underl ist keines davon.}%
% engl. "I got 99 problems, but __ ain't one"
[...]

Das sieht doch schon mal sehr gut aus, da es strukturiert ist. Die weißen Karten sind jeweils durch den Befehl \whitecard{Kategorie}{Text} gegeben und bei den schwarzen Karten analog, wobei dort zusätzlich noch die Anzahl an zu legenden Karten mit angegeben ist. Das passt schon ziemlich gut zu dem, was wir in unserer json brauchen und lässt sich auch recht einfach mit Python parsen. Fangen wir mal an und legen uns ein Objekt an, dass die json-Struktur von oben repräsentiert. Anschließend suchen wir alle *.tex-Dateien im Verzeichnis (categories/) und lesen alle Zeilen ein. Das komplette Script gibt es hier im Gist.

import json
import glob

cards = {'blackCards': [], 'whiteCards': [], 'Base': {'name': 'Base Set dt.', 'black': [], 'white': []}}

tex_files = glob.glob("*.tex")
for tex in tex_files:
  with open(tex, 'r') as f:
    lines = f.readlines()

Damit haben wir jetzt eine große Liste von Strings, welche die einzelne Zeilen der Datei enthält. Die müssen wir jetzt einzeln verarbeiten, daher schauen wir uns die individuellen Zeilen einmal an.

Wie auch oben im Beispiel zu sehen, beginnen einige Zeilen mit einem Prozentzeichen. So werden in LaTeX Kommentare eingeleitet. Diese Zeilen können wir ignorieren und springen mittels continue einfach in die nächste Zeile.

for line in lines:
	if line[0:1] == '%':
		continue

Jetzt wird es etwas trickreich. Ich zerteile die Zeile jeweils an der Zeichenkette }{. Ein kleines Beispiel für die schwarze Karte oben:

>>> '\blackcard{1}{Basis}{Ich habe 99 Probleme, \newline aber \underl ist keines davon.}%'.split('}{')
['\blackcard{1', 'Basis', 'Ich habe 99 Probleme, \newline aber \underl ist keines davon.}%']

Aus dem einzelnen String werden nun drei Strings. Man sieht nun schon, dass im ersten Teil die Anzahl Karten ist und im letzten Teil die Frage. Ein bisschen schön müssen wir die Teile aber noch machen, denn das \blackcard{1 wird nicht als 1 interpretiert.

Aber erstmal schauen wir, was für eine Karte wir den haben. Dazu schauen wir einfach, was eigentlich in den Zeichen 1-5 der Zeile steht. Hier kommt uns die Repräsentation von Strings in Python entgegen, da wir hier einfach einen List-Operator verwenden können: Der erste Paramter gibt den Start an und der zweite Parameter das Ende an, wobei dieser Werte exklusiv, also nicht mehr in der Liste ist.

Ähnlich machen wir das auch für den Pick, hierbei nutzen wir aus, dass negative Werte entsprechend vom Ende gerechnet werden. Wir gucken uns also nur das letzte Zeichen bis zum Ende an, da wir kein Ende explizit angegeben haben. Im anderen Fall des Texts (data) nutzen wir es andersherum und schneiden die letzten 3 Zeichen ab, was }%\n ist. Wo kommt jetzt das \n her? Das ist ein Zeilenumbruch, der noch in der Zeile ist, aber nicht explizit angezeigt wird.

Mittels replace() machen wir die Fragen noch schön und ersetzen einige LaTeX Besonderheiten, z.B. wird der LaTeX-Unterstrich \\underline ein einfacher Unterstrich _. Anschließend fügen wir die Karten unserer Liste an schwarzen bzw. weißen Karten hinzu. Bei den schwarzen müssen wir hier das dict erstellen, dass zusätzlich auch die Anzahl an zu spielenden Karten enthält.

split = line.split('}{')

if line[1:6] == 'black':
    pick = split[0][-1:]
    data = split[2][:-3].replace('\\newline', '<br />').replace('- ', '').replace('\\SymbReg', '').replace('\%','%').replace('\\underl', '_').replace('\'\'', '"').replace('``', '"')
    cards['blackCards'].append({"text": data, "pick": pick})

if line[1:6] == 'white':
	data = split[1][:-3].replace('\\newline', '<br />').replace('- ', '').replace('\\SymbReg', '').replace('\%','%').replace('\\underl', '_').replace('\'\'', '"').replace('``', '"')
    cards['whiteCards'].append(data)

Jetzt haben wir das meiste schon geschafft. Wir haben die TeX-Sources in unsere Struktur überführt, jetzt müssen wir noch ein Set anlegen. Dafür schreiben wir einfach alle die Nummern aller unserer Karten in die Liste. Indizes fangen in Python bei 0 an, daher haben wir im folgenden range(0, Anzahl an Karten). Auch hier ist der zweite Parameter exklusiv, d.h. es ist das Interval [0, Anzahl Karten). Die Syntax ist jeweils die Kurzform für eine Schleife, die jede Zahl zwischen 0 und Anzahl Karten - 1 in die Liste cards['Base']['black'] bzw. cards['Base']['white'] einfügt. Abschließend schreiben wir unser Set noch in eine cards.json, die wir nun auf den Server kopieren können und nach einem Neustart der CaH-Instanz nutzen können.


cards['Base']['black'] = [i for i in range(0, len(cards['blackCards']))]
cards['Base']['white'] = [i for i in range(0, len(cards['whiteCards']))]

with open('cards.json', 'w') as f:
    json.dump(cards, f)

Mehr Kartensets

Bei der Recherche nach den deutschen Karten war ich auf das Projekt JSON Against Humanity gestoßen, welches eine Vielzahl an unterschiedlichen Kartensets anbietet. Ein kurzer Blick in die Source zeigte, dass es hier jeweils eine black.md.txt und eine white.md.txt gibt, welche die Karten enthalten.

Das lässt sich auch recht leicht parsen, größtes Problem war die Erkennung, wie viele Karten der Spieler legen muss. Aber auch das lässt sich in Python elegant lösen:

max(1, line.count('_'))

Es wird einfach die Anzahl an Unterstrichen auf der schwarzen Karte gezählt. Da nicht alle Karten einen Unterstrich haben, wird das Ergebnis in die max-Funktion gegeben, die den höheren Wert zurückgibt. Somit ist sichergestellt, dass pick immer mindestens 1 ist.

Gleichzeitig sollten nun auch mehrere Karten-Sets möglich sein, daher brauchte die Logik für die Referenzierung der Karten in den Sets noch ein kleines Update. Zu Beginn des Einlesevorgangs wird die aktuelle Anzahl an weißen und schwarzen Karten abgefragt. Diese Zahl ist, nach dem Hinzufügen der Karten dieses Sets, der Startwert für die Referenzierung über die Indizes. Diese laufen dann wieder bis zur Anzahl der Karten - 1. Elegant, oder?

Eine kleine Veränderung zum Repo ist noch, dass die Dateien jetzt als Konvention jeweils [name].black und [name].white heißen müssen.

def get_pack(name, index):
    start_black = len(cards['blackCards'])
    start_white = len(cards['whiteCards'])

    with open(name + '.black', 'r') as f:
        for line in f.readlines():
            if len(line) > 0:
                cards['blackCards'].append({"text": line, "pick": max(1, line.count('_'))})

    with open(name + '.white', 'r') as f:
        for line in f.readlines():
            if len(line) > 0:
                cards['whiteCards'].append(line)

    cards[index] = {'Name': name}
    cards[index]['black'] = [i for i in range(start_black, len(cards['blackCards']))]
    cards[index]['white'] = [i for i in range(start_white, len(cards['whiteCards']))]

get_pack('prtg', 'Downtime')

Auswahl des Sets

Die Original-Variante von CaH hatte keine Auswahl des Sets im Frontend. Im Backend waren die Sets schon vorgesehen, aber die Auswahl war nicht möglich. Also habe ich mit etwas fluchen ins React-Frontend noch die Auswahl des Sets integriert. Dabei kam dann der Wunsch auf, auch weiterhin die Original-Variante spielen zu können. Also kleine Anpassung am Script: Wir laden zuerst mal das englische Original und ergänzen dann unsere Karten. Statt also das cards-Objekt zu initialsieren, lesen wir einfach die bestehende, originale cards.json.

with open('en.json', 'r') as en:
    cards = json.load(en)

Da wird jetzt schon einiges an Karten in den Liste haben, müssen wir unsere Referenzen für das Set entsprechend anpassen. Statt bei 0 zu starten, müssen wir hier, analog zu den zusätzlichen Sets, vor dem Hinzufügen der Karten zählen, wie viele Karten schon in der Liste sind und dann dort beginnen.

Eigene Kartensets

Nach dieser Vorarbeit lassen sich nun einfach und elegant weitere Kartensets anlegen. Es müssen einfach nur zwei Textdateien mit den vorgesehen Begriffen gefüllt werden und diese anschließend geparst werden. Das führte dann auch zu der Generierung eines Sommerfest-Sets. Schnell waren ein paar schwarze Karten und viele weiße Karten definiert und als Crowdsourcing in einem Cryptpad werden noch weitere Begriff gesucht und bald ergänzt.

Ein kleiner Auszug:

schwarz:
Das Wohnheim ist so leer ohne _.
_ auf der Bühne - ein Traum!
Ohne _ ist kein Sommerfest.

weiß:
Sommerfest-Keller
Kabeltrommel
RageCage
Band
Partyraum
ballern
Hemelinger
Bierdusche

Cards Against Muggles

Eine Besonderheit ist die Variante Cards Against Muggles. Hier gibt es nur eine PDF mit den Karten, aber keine Textdateien. Mittels des Unix-Tools pdftotext lässt sich die PDF aber einfach in eine Textdatei konvertieren und nach kleinen Korrekturen kann man dann zwei Textdateien (black/white) draus machen, die sich auch einfach parsen lassen. Da die Karten nicht free sind, müsst ihr etwas zaubern, um sie spielen zu können :-)

Automatische Benachrichtigungen aus dem Schichten-Tool

Eike Broda — Mon, 15 Apr 2019 10:00:00 +0000

Das Schichten-Tool vom Sommerfest hat ein paar kleine Updates bekommen, zudem wurden ein paar Fehler gefixt.

Neue Features

Bei den Optionen für den Schichtplan gibt es nun zwei neue Optionen: “Keine Eintragungen vor …” und “Eintragungen bis dahin deaktivieren”. An sich sind die beiden Funktionen selbsterklärend, trotzdem noch eine kurze Erläuterung, wieso und was überhaupt.

Um allen aus dem Team gleiche Chancen auf gute Schichten zu geben, sollen Schichten mit etwas Vorlauf angekündigt werden und die Eintragungen auch dann erst möglich sein. Da das mit dem Ankündigen immer nicht so richtig gut geklappt hat, gibt es nun zwei zusätzliche Optionen im Schichten-Tool. Die erste Option “keine Eintragungen vor” ermöglicht einen Unix-Zeitstempel¹ anzugeben, ab wann sich Staffler (wieder) für Schichten eintragen können. Basierend darauf wird auch ein Hinweis im Schichtplan mit diesem Datum & Uhrzeit angezeigt.

Die zweite Option “Eintragungen bis dahin deaktivieren” ermöglicht zusätzlich den Schichtplan für jegliche Eintragungen durch Staffler zu deaktivieren. Bis zum gegebenen Datum (s.o.) sind keinerlei Eintragungen von Schichten im Plan möglich. Diese lassen sich erst wieder ab dem zuvor definierten Zeitpunkt eintragen. Durch diese zusätzliche Option soll die Eintragung in zwei Wellen ermöglicht werden, wie z.B. erste Schicht, dann zweite Schicht. Vor der ersten Eintragung ist die Option aktiv und nach der zweiten dann nicht mehr.

Die Optionen sollten auch ruhig direkt bei der Erstellung genutzt werden, damit Staffler, die im Schichten-Tool vorbeischauen, direkt wissen, dass der Plan noch in Arbeit ist und Eintragungen erst später möglich sein werden.

Durch das erste Feature sind nun auch automatische Benachrichtigungen mittels Webhook im Slack-Channel #announcements möglich. Hierbei erfolgen Benachrichtigungen zwei Tage, drei Stunden und zum Beginn der Eintragung (bzw. zu beginnenden Eintragungen im Laufe der nächsten Stunde). Diese Zeiten sind erst einmal willkürlich festgelegt und können einfach angepasst werden. Sie sind aber hoffentlich ausreichend, um den Schichtvergabeprozess fairer und transparenter darzustellen. Nachfolgend ein Beispiel, wie das ganze dann in Slack aussieht:

heute, 09:00 Uhr
Vorankündigung: Ab Montag, 15.04.2019 12:00 könnt ihr euch in den Schichtplan VoFi 2019 - Plakatieren & Flyern eintragen.

heute, 12:00 Uhr
Ihr könnt euch jetzt in den Schichtplan VoFi 2019 - Plakatieren & Flyern eintragen. (Zugangsdaten: Benutzer …)

Das ganze ist über einen Cronjob gelöst, der jeweils zur vollen Stunde prüft, ob für einen Schichtplan benachrichtigt werden muss. Daher empfiehlt es sich, immer Schichten zur vollen Stunde freizuschalten. Sofern Schichten aber erst später in der Stunde freigeschaltet werden, wird die Zeit in Minuten bis zur Freischaltung angegeben. Eine zusätzliche Benachrichtigung zum finalen Zeitpunkt erfolgt dann nicht mehr.

Und wo ich gerade dabei war, habe ich das Layout des Neu/Bearbeiten-Dialogs auch noch fix etwas überarbeitet.

Die Tage eines Schichtplans können nun sortiert werden. Dafür kann jedem Tag eine Sortierung zugewiesen werden. Diese Sortierung ist einfach eine Nummer und es wird absteigend sortiert; der Tag mit der höchsten Nummer kommt also als erstes. Standardmäßig ist die Sortierung für alle Tage 1, sodass diese dann nach dem Erstellungsdatum sortiert werden. Die Sortierung kann nur nachträglich per Bearbeitung angepasst werden.

Fixes

Beim Abmelden gab es im ersten Versuch immer eine Fehlermeldung, dass keine Schichten mehr frei sind. Die Ursache war ein Features, das im letzten Jahr neu implementiert wurde und jeweils nach dem ersten Absenden prüft, ob in der angegebenen Schicht überhaupt noch Plätze frei sind. Somit soll sichergestellt werden, dass bei parallelen Eintragungen nicht mehr als die “zulässige” Anzahl an Schichten eingetragen wird. Allerdings ist die Abmeldung ein Sonderfall, für welche diese Begrenzung nicht gilt. Dieser Fall wurde allerdings nicht ausgeklammert, wodurch weiterhin immer abgefragt wurde, ob in der Schicht noch was frei ist … ist jetzt behoben.

Es gab in einigen Fällen ein paar unschöne Darstellungen, wenn irgendwo noch Werte fehlten. Das ist durch einige zusätzliche isset()-Checks ebenfalls behoben.

Das sind die Sekunden seit dem 01.01.1970, 00:00. Für Programmierer eine einfachere Weise, um mit Datum & Zeit zu rechnen. Für die Konvertierung eines Datums & Uhrzeit in Unixtime gibt es entsprechende Webseiten, z.B. unixtime.de. ^zurück

Benutzerstatiken mit Fathom

Eike Broda — Thu, 21 Mar 2019 11:30:26 +0000

Vor einiger Zeit bin ich zufällig beim Surfen auf Fathom gestoßen. Ein Tracking-Tool für Webseiten wie Google Analytics oder Matomo, dass allerdings die Privatsphäre der Nutzer in den Mittelpunkt stellt und nur sehr einfache Statistiken bereitstellt, die aber letztendlich vollkommen ausreichend sind.

Der Vorteil gegenüber Matomo ist, dass die Statistiken deutlich schneller laden. Matomo ist leider auf meinem Hoster ziemlich langsam, wenn es darum geht die Daten zu konsolidieren. Vielleicht hätte ich das noch tweaken können, aber letztendlich habe ich eh eher selten in die Statistiken geguckt, daher habe ich Matomo auf allen Seiten wieder entfernt. Auch um mir nebenbei die super-hässlichen Cookie-Hinweise zu sparen, die inzwischen auf jeder Webseite aufploppen und aus technischer Sicht doch ziemlich fragwürdig sind.

Jetzt aber Fathom. Ich fand’s cool, hatte aber keine Seite um es zu testen. Jetzt möchte ich aber wissen, ob das hier irgendwer liest, daher habe ich es jetzt hier mal testweise eingebunden. Also wenn ihr nicht getrackt werden wollt, aktiviert einfach Do Not Track in eurem Browser. Fathom respektiert das.

Für die Transparenz sind die Statistiken jetzt auch öffentlich verfügbar¹. Schaut einfach mal rein; aus meiner Sicht reichen die angebotenen Statistiken vollkommen aus.

Fathom kann einfach auf einem eigenen Server installiert werden. Somit bleiben zusätzlich alle Daten auch bei euch. Also anders als z.B bei Google Analytics. ~~Ich werde später auch eine Anleitung für das Uberlab verfassen,~~ Es gibt eine Anleitung im Uberlab dazu, wie einfach man Fathom auf einem Uberspace 7 deployen kann². Funktioniert nun ziemlich nice mit den neuen Web Backends.

Auf dem legacy Uberspace 6 funktioniert Fathom aufgrund eines zu alten Kernels mit der aktuellen Version nicht mehr. Es stürzt da direkt beim Start mit einer Fehlermeldung ab. Da hilft dann nur der Wechsel auf die neue Uberspace-Version …

[me@host bin]$ ./fathom -v
FATAL: kernel too old
Abgebrochen

Die Statistiken sind momentan nicht mehr öffentlich, da in einem Projekt auch private URLs mitgetrackt werden, die nicht öffentlich zugänglich sein sollten. Security by Obscurity ist natürlich (k)ein Top-Konzept, aber hier reicht es aus. ^zurück
Update April 2020: Ich habe es endlich geschafft den Guide zu schreiben. Seit Ende April ist der Guide nun Teil des Uberlabs. ^zurück

T-Shirts bestellen via Slack

Eike Broda — Wed, 20 Mar 2019 20:22:30 +0000

Für die komplette Crew des Sommerfests gibt es jedes Jahr ein entsprechendes T-Shirt, intern Staff-Shirt genannt. Dieses Shirt ist jeweils in der Farbe des Jahres und mit einem Staff-Aufdruck. Dabei für das ganze Team den Überblick zu behalten, wer schon ein T-Shirt bestellt hat und wessen T-Shirt noch fehlt ist gar nicht so einfach. In den letzten Jahren haben wir das üblicherweise mit einem GoogleDocs-Formular gemacht, wo sich dann alle Leute aus dem Team eintragen mussten. Allerdings hatte auch das einige Probleme: So haben sich teils Staffler nur mit ihrem Vorname eingetragen. Ist an sich okay, nur blöd, wenn es im Team noch jemanden mit demselben Vornamen gibt. Alleine über die Größe kann man dann schwer rückschließen, wer noch fehlt. Auch war die Transparenz teils nicht gegeben: Welche Größe habe ich nochmal bestellt und habe ich schon bestellt?

Bestellen per Slack?

Das soll in diesem Jahr anders laufen. In einem Sommerfest-Protokoll von einem Treffen, auf dem ich verhindert war, las ich dann, dass die Bestellung per Slack ablaufen soll. Wir kommunizieren seit Beginn des diesjährigen Orga-Zyklusses über das “neuartige” Slack. Läuft schon gut, aber irgendwie las sich das zu wenig technisch. Meine Vision war eigentlich, dass auch mit ins Orga-Tool einzubauen. Aber das müsste man dort erst implementieren und das Tool ist ja auch noch nicht alpha und nicht richtig genutzt. Von daher ist Slack als Ort der Aktiven schon eine bessere Idee. Aber es muss doch was besseres geben, als alle schreiben ihre Größe in einen Channel und jemand Armes darf das dann am Ende auswerten. Was dann leider auch immer wieder zu Problemen führt, weil man dann doch mal eine Shirt vergisst oder irgendwo ein Girlie statt einem normalen Shirt bestellt.

Aber wie kann man das technisch besser lösen?

Die erste Idee waren Slack-Commands (Slash-Commands), so bieten Integrationen und auch Slack selbst Befehle wie z.B. /giphy [keyword] an. Das Beispiel sucht dann auf Giphy nach einem Gif und bietet dem Nutzer die Möglichkeit das zu posten. Sowas müsste sich doch auch für die Bestellung der Staff-Shirts basteln lassen. Kann ja nicht so schwer sein. Die erste Idee wäre dann /staffshirt girlie m gewesen, also dass der Nutzer dann sein Bestellung als Parameter übergibt. Der gute Niko hat dann aber mal ein bisschen in den Slack-Docs gewühlt und kam mit Dialogs “um die Ecke”. Das ist ein Slack-Feature, was es ermöglicht in Slack einen Eingabedialog zu öffnen, in dem die Nutzer was eingeben und dann abschicken können. Das klingt nochmal deutlich besser.

Der Plan war nun also: Durch einen Befehl den Prozess intiieren, einen Dialog anzeigen und den Nutzer seine Bestellung machen lassen.

Let’s go. Dialog implementieren

Klingt erstmal einfach, aber irgendwie muss man doch recht viel machen, damit es dann funktioniert. Aber ein bisschen Step-by-step. Los geht’s mit einer eigenen Slack-Anwendung. Die kann man sich einfach online klicken, wenn an in einem Workspace ist. Das gute ist, dass die Apps dann auch erstmal nur für den Workspace sichtbar sind. Man muss sich also keine Gedanken darüber machen, dass irgendwer in der Welt sich jetzt diese App installiert.

Nun muss man die App im Workspace installieren, damit man das notwendige OAuth-Token bekommt um weitere Aktionen auszuführen. Dafür muss die App aber mindestens eine Berechtigung anfordern. Ich habe da einfach mal “Send messages as Sommerfest-Tools (chat:write:bot)” als Berechtigung ausgewählt, da später die App dem Nutzer eine Bestätigung als Nachricht schicken soll. Danach kann man die App dann dem Workspace hinzufügen und bekommt hinterher auch das OAuth-Token für die Authentifizierung. Das sieht dann so ähnlich aus: xoxp-12345678901-12345678901-123456789012-1234567890abcdef1234567890abcdef.

Nun kanns losgehen. Ebenfalls im dem Slack-Webportal können für die App die Slash commands definiert werden. Es muss angegeben werden, was der Befehl ist. Okay, easy /staffshirt. Dann eine Request URL, okay … lassen wir erstmal offen und dann noch eine Beschreibung, die Slack in der Vorschau für den Befehl zeigt und ein Hinweis zur Nutzung, auch für die Autovervollständigung. Speichern. Hmm, ne - Slack sagt, leer ist keine gültige Request URL. Aber da ist ein kleines Info-Zeichen in dem Feld, das sagt was die URI ist.

We’ll send an HTTP POST request with information you might need to this URL when the command is run.

Okay, also brauche ich irgendwo einen Service der einen POST-Request empfangen kann. Die Sourcen vom Orga-Tool hatte ich gerade nicht auf’m Rechner und nur dafür irgendwo extra ein Flask zum Laufen zu bringen, war mir dann zu viel. Daher die einfachste Variante genommen, die mit jedem SharedHost funktioniert: PHP. Da kümmert sich selbstständig der Apache darum, dass das läuft und ich kann mir super einfach den Payload holen:

<?php
var_dump($_POST);

So kann ich mir das dann dumpen, okay - ist etwas blöd bei nem Slack-Request, weil ich seh ja gar nicht, was genau Slack mir da schickt. Ich bekomme den Output ja nicht zu sehen ¹. Von daher vielleicht besser den Input nehmen und in eine Datei schreiben. Das ist ja auch easy in PHP. In diesem Fall speichere ich einfach den kompletten POST-Request als json und häng’ jeden Request einfach immer an die Datei post_requests.txt an.

<?php
file_put_contents('post_requests.txt', json_encode($_POST), FILE_APPEND);

Schaut man sich dann an, was Slack einem schickt, so sieht man, dass es die nachfolgenden Elemente sind.

token:UZ3stU0rMIMTAWxxXXXXxXxX
team_id:ABCDEFGH
team_domain:some-slack
channel_id:XXXXENGL
channel_name:directmessage
user_id:UDYKDXXXX
user_name:ebroda
command:/staffshirt
text:
response_url:https://hooks.slack.com/commands/XXXXXXRYT1/580296238656/G3sOdzYyiGp7efvlT7xXxxxX
trigger_id: 582673415332.84734882919.0d06e430f7749f98742444xxx4xxx978

Für die bessere Lesbarkeit hier als Key-Value-Pairs dargestellt². Eigentlich kommt das ganze als application/x-www-form-urlencoded, aber PHP parst das automatisch, daher kann man in der $_POST-Variable von PHP direkt mit den Keys auf die Werte zugreifen. Details zu den einzelnen Zeilen finden sich in der Erläuterung in der Slack-API.

Entscheidend ist in dieser Antwort die trigger_id. Diese wird benötigt um dem Nutzer dann einen Dialog anzeigen zu können. Auf diese kann nun einfach über $_POST zugegriffen werden.Mittels des nachfolgenden Schnipsels, bekommen wir also die Trigger-ID.

<?php
$trigger = $_POST['trigger_id'];

Um dem Nutzern nun unseren Dialog anzuzeigen, muss ein POST-Request auf den dialog.open-Endpoint der Slack-API erfolgen. Dabei sind noch einige Stolpersteine zu beachten, wie Slack den Request gerne hätte. Eine Möglichkeit ist den Request mit den Optionen als JSON-String im Request-Body zu schicken. Dafür muss die Nachricht dann aber auch den entsprechenden Content-Type application/json aufweisen und im Header das Slack-Token von der Installation als Authorization-Header mit dem Prefix Bearer enthalten³. Die nachfolgende Funktion setzt diese Problematik um und basiert auf dieser Stackoverflow-Antwort.

function send_to_slack($uri, $data) {
  $slack_token = "xoxp-1234567890..."

  $options = array(
      'http' => array(
          'header'  => "Content-type: application/json; charset=utf-8\r\nAuthorization: Bearer " . $slack_token,
          'method'  => 'POST',
          'content' => json_encode($data)
      )
  );
  $context  = stream_context_create($options);
  return file_get_contents($uri, false, $context);
}

Was macht die Funktion? Sie erwartet eine URL (den API-Endpoint) und die Daten (als array). Dann wird ein zusätzliches Array erstellt, dass alle Einstellungen für den POST-Request setzt. In diesem Fall also zwei Header, den Content-Type und die Authorization; die Methode, hier POST sowie den Request-Body a.k.a. content der Nachricht. Anschließend wird das ganze verschickt und das Ergebnis zurückgegeben. Gegenüber der Stackoverflow-Antwort habe ich den Fehlerfall mal weggelassen, um es einfach zu halten. Wir gehen ja nicht davon aus, dass beim Request irgendwas schief läuft bzw. wir merkens spätestens, wenn nichts passiert.

Während der Entwicklung lohnt es sich auf jeden Fall die Antwort der API einfach auszugeben um Fehlermeldungen von Slack in dem Channel zu erhalten, in dem man den Befehl ausgeführt hat.

Dialog designen

Wir haben die Trigger id, wir können einen POST-Request absetzen, jetzt müssen wir den Dialog definieren und dann Anzeigen lassen. Dafür defineren wir erstmal allgemein den Dialog, also z.B. welchen Titel der Dialog hat und wie der Button zum Abschicken beschriftet ist. Die _callbackid bekommen wir nach dem Absenden von Slack wieder zurück, um den Dialog zu identifizieren. Das _notify_oncancel-Flag bewirkt, dass auch bei einem Klick auf Abbrechen später ein Request abgeschickt wird, sodass der Nutzer z.B. per Nachricht informiert werden kann, dass er den Prozess abgebrochen hat und kein Shirt bestellt wurde. Die eigentlichen Formularfelder werden in der Liste elements definiert.

{
  "callback_id": "staffshirt",
  "title": "Staff-Shirt bestellen",
  "submit_label": "Bestellen",
  "notify_on_cancel": true,
  "elements": []
}

Dafür kennt Slack 3 verschiedene Feldtypen⁴, die verwendet werden können: Text, (längeres) Textfeld und eine Auswahlliste. Für die Bestellung des T-Shirts soll der Nutzer die Größe des T-Shirts aus einer Liste von vorgegebenen Größen auswählen können. Dadurch gibt es zum einen nur Bestellungen in Größen, die es auch wirklich gibt und zum anderen macht das später die Auswertung einfacher.

Die Definition eines Auswahlfelds für die Größen S, M, L und XL sieht dann so aus. Dabei ist jeweils Label das, was angezeigt wird. Der Type gibt an, dass es sich um eine Auswahlliste handelt und das name-Attribut ist später für die Auswertung, wenn der Nutzer das Formular abschickt.

{
  "label": "Größe",
  "type": "select",
  "name": "shirt_size",
  "options": [
    {
      "label": "S",
      "value": "s"
    },
    {
      "label": "M",
      "value": "m"
    },
    {
      "label": "L",
      "value": "l"
    },
    {
      "label": "XL",
      "value": "xl"
    }
  ]
}

Haben wir so das Formular definiert, muss das alles zusammen in JSON gepackt werden und abgeschickt werden. Das kann dann wie nachfolgend aussehen. Die Funktion zum Senden wurde gekürzt.

<?php
    $trigger = $_POST['trigger_id'];

    function send_to_slack($uri, $data) {
      // ... (s.o.)
    }

    $data = array(
        'trigger_id' => $trigger,
        'dialog' => array(
            'callback_id' => 'staffshirt',
            'title' => 'Staff-Shirt bestellen',
            'submit_label' => 'Bestellen',
            'notify_on_cancel' => true,
            'elements' => array(
                array(
                    'label' => 'Größe',
                    'type' => 'select',
                    'name' => 'shirt_size',
                    'options' => array(
                        array('label' => 'S', 'value' => 's'),
                        array('label' => 'M', 'value' => 'm'),
                        array('label' => 'L', 'value' => 'l'),
                        array('label' => 'XL', 'value' => 'xl')
                    )
                )
            )
        )
    );

    send_to_slack('https://slack.com/api/dialog.open', $data);

Damit Slack die Dialoge auch anzeigt, muss das in der App aktiviert werden. Dafür muss wieder im Webinterface von der Slack-Anwendung die Nutzung von Interactive Components aktiviert werden. Dabei muss eine Request URL angegeben werden. An diese URL postet Slack jedes Mal, wenn ein Dialog oder ein anderes interaktives Element (Buttons, Actions, Message Menues) von einem Benutzer angeklickt bzw. abgeschickt wird. Um den Endpoint für die Actions geht es in einem zweiten Teil.

Ergebnis

Das ganze nun auf einen Server deployed, die URLs in der Slack-Konfiguration angepasst und ab dafür. Und tatsächlich auf eine Eingabe von /staffshirt öffnet sich ein Dialog:

Der Dialog zur Auswahl der T-Shirtgröße

Auswahl einer T-Shirtgröße

Ausblick

Der erste Dialog ist da, damit kann der Teil schon als abgeschlossen angenommen werden. Der T-Shirt-Typ, die Auswahl eines Extra-Shirts sowie die Möglichkeit noch einen Kommentar anzugeben lässt sich nun leicht noch ergänzen. Im nächsten Teil wird es dann um das Speichern der erhaltenen Werte gehen und in einem dritten Teil um die Generierung einer Liste der Bestellungen, der Kummulierung der einzelnen Größen sowie eine Liste aller, die noch nicht bestellt haben.

Die Implementierung ist schon fertig, ich hatte nur noch keine Zeit, dazu auch einen entsprechenden Post zu schreiben.

Tatsächlich zeigt Slack einem sogar doch die Rückgabe des POST-Requests als “nur für dich sichtbare”-Nachricht an. ^zurück
Und ein paar der Variablen sind verändert/obfuscated. ^zurück
Detailliert beschrieben werden die Anforderungen in der Slack-API-Dokumentation. Dieser spezielle Punkt hier. ^zurück
Details zu den einzelnen Typen finden sich in der Slack-Doku. ^zurück

Vision: Das Orgatool - Alles Wichtige für die Sommerfest-Orga an einem Ort

Eike Broda — Wed, 20 Mar 2019 20:20:30 +0000

Im Februar 2017 habe ich angefangen ein Orga-Tool zu entwickeln. Eine Problematik war zum einen eine mangelhafte Mitgliederverwaltung. Bisher wurden die Mitglieder in einer Excel-Liste in einer Dropbox verwaltet. Diese Liste wurde aber eher selten gepflegt und war auch nicht hinreichend zugänglich, geschweige denn aktuell, so z.B. Mitglieder umgezogen sind. Eine Vision war daher einen zentralen Ort in einer Webanwendung zu schaffen, in dem alle Mitglieder verwaltet werden und diese gleichzeitig die Möglichkeit haben ihre Daten selbst zu verwalten. Auch die Zahlung des Mitgliedsbeitrags wurde dort nur kurz in der Excel-Tabelle vermerkt.

Das nächste Problem war, dass wiedermal diverse Leute ihr Passwort für das Bandvoting vergessen hatten oder sich erst gar nicht registriert hatten. Daher war die Vision auch, dass die Leute mit ihrer Anmeldung im Orga-Tool auch direkt einen Sommerfest-Account bekommen, mit dem sie sich in allen Tools anmelden können. Geplant ist dafür irgendwann mal ein LDAP-Server bereitzustellen, gegen den die Anwendungen dann validieren können.

Ein dritter Aspekt war die Mitglieder einfacher zu erreichen. Bisher wurde die Rundmail-Funktion im Forum genutzt, um allen Mitgliedern dort eine E-Mail zu schicken. Das war aber nicht optimal, weil dazu die Sendenden immer Zugriff auf die Adminstration haben mussten. Als Vision war auch eine Art “Weekly Digest” angedacht, welcher einmal wöchentlich über die letzten Aktivitäten informiert und eine Übersicht der nächsten Termine gibt. Dieser sollte dann aber auch automatisch generiert werden. Wozu haben wir schließlich Computer?

Das Sommerfest ist zudem in verschiedenen Ressorts organisiert. Um einen Überblick zu bekommen, wer was macht, sollte das Orga-Tool auch diese Ressortstruktur abbilden und sichtbar machen, welche Mitglieder in den einzelnen Ressorts sind.

Leider ist das Orga-Tool bis heute nicht fertig, die Priorität für das Tool war leide eher niedrig. Die Visionen sind aber weiterhin erhalten. Ein paar Aspekte sind davon umgesetzt, so gibt es die Mitglieder, die Ressorts und zusätzlich auch Termine. Die Termine werden sogar mittels CalDav ausgeliefert, sodass man sie abonnieren kann und einfach alle Sommerfest-Termine in seinen Kalender bekommt¹. Zusätzlich gibt es auch die Möglichkeit für jeden Termin ein Protokoll in Markdown zu tippen und dort zu hinterlegen. Soweit so gut, leider fehlen immer noch diverse Funktionalitäten und das Tool ist bis heute eher ‘ne alpha als ‘ne beta. Cool an der Sache ist auch die Integration in Slack, wobei Integration momentan noch recht hoch gegriffen ist. Tatsächlich postet das Tool “nur” bei jedem neuen Termin diesen auch automatisch in Slack. Ist nicht mehr als ‘n Webhook, aber trotzdem cool…

Um es mal niederzuschreiben nachfolgend noch die weiteren Visionen für das Orga-Tool:

Die Mitgliederverwaltung endlich vollständig, mit allen Funktionalitäten, die ich mir oben so ausgedacht hatte. Auch z.B. die Möglichkeit einfach online mittels Klick seine Kündigung einzureichen und somit seinen Account einfach zum Jahresende auslaufen zu lassen. Es sollte so easy sein, dass auch die Mitglieder selbst somit die Liste der Aktiven pflegen. Wer raus ist, ist dann raus. Gleichzeitg soll der Beitritt auch möglichst einfach sein. Im besten Fall können wir das auch alles in einem großen Formular erledigen, an dessen Ende man dann ein PDF generiert bekommt, das ausdruckt und unterschreibt und dann schon Mitglied ist. Der Mitgliedsbeitrag soll sich dann einfach per PayPal bezahlen lassen und wenn man die Transaktion abgeschlossen hat, wird der Betrag automatisch auch als bezahlt verbucht.

Was zum nächsten großen Punkt führt: Die Finanzverwaltung. Auch das ist momentan ein großes Excel-Sheet mit ein klein bisschen Logik. Besonders schön finde ich das aber nicht. Aus mehreren Gründen. Oder Visionen, wie es eigentlich laufen sollte. Dazu hole ich mal ein bisschen aus. Jedes Ressort sollte einen gewissen finanziellen Rahmen haben (Budget) in dem es ohne weitere Zustimmung seine Einkäufe tätigen kann, zumindest für Artikel kleiner einem bestimmten Wert von n €. Diese Budget gibt es momentan nicht in dieser Excel-Tabelle. Dafür gibt es noch eine Extra-Tabelle, zumindest endlich in diesem Jahr mal. Aber wie cool wäre es, wenn jedes Ressort direkt sehen würde, wie viel Budget es noch hat? Und wie viel Geld es schon ausgegeben hat? Auch insgesamt für die Transparenz im Team wäre es gut.

Das erfordert dann aber auch, dass alle Buchungen im Tool verbucht werden. Momentan passiert das in der Excel-Tabelle, somit ist der Aufwand etwas höher, wenn man mehrere Rechnungen hat. Aber hier soll die Webapp einen Vorteil ausspielen, indem sie den Finanzer entlastet und zwar dadurch, dass die Staffler ihre Rechnungen direkt selbst eintragen und hochladen können. Der Finanzer prüft anschließend nur noch die Rechnung und checkt die Eintragung nochmal gegen. Würde ein paar Sachen auch vereinfachen. Genauso das Auffinden von Rechnungen und der Rechnungsdokumente. Die haben nun recht kryptische Dateinamen nach dem Muster [#ressort Ressort]/[#ressort]_[#lfdNummer].pdf bekommen. Der Dateiname steht mit in der Excel-Tabelle. Somit kann man über die Buchung dann die Rechnung finden, aber das ist auch eher umständlich, sich dann noch durch Ordner zu klicken und die richtige Datei zu suchen anstatt einfach direkt auf einen Button “Rechnung” zu klicken und das PDF angezeigt zu bekommen.

Zusätzlich ist momentan die Abrechnung von Auslagen ein größeres Thema. Einige Leute im Team² sammeln so einiges an Auslagen an, die dann irgendwann abgerechnet werden müssen. Dabei kann aber auch schon mal was unter den Tisch fallen, dann wird mal ne Rechnung vergessen. Auch das sollte das Orga-Tool abnehmen, indem es auch einen Bezahlt-Status kennt, also wer die Rechnung beglichen hat und automatisch alles aufaddiert, was der Nutzer momentan an Auslagen hat. Auch Vorschüsse für Ausgaben, wenn es also vorab Geld gibt, können dort auch einfach verbucht werden und alles wird transparenter und nachvollziehbarer. Wenn man dann noch einen Änderungslog mit integriert, dann macht das Sachen noch einfacher. Insgesamt soll das auch mehr Statistiken bringen. Wie oben schon angesprochen, die Transparenz der einzelnen Ressorts - das soll sich später auch allgemein für die Finanzen finden. Zum Beispiel auch die Entwicklung der Ausgaben über mehrere Jahre … solche Sachen. Zudem soll für jede Buchung auch abgefragt werden, ob es sich um eine einmalige Ausgabe (z.B. Anschaffung) handelt oder eine jährliche Ausgabe. So wird auch eine erste grobe Budgetschätzung einfach mit einem simplen Query möglich.

Beim Thema Anschaffungen kommen wir dann auch zu einer anderen Sache, die momentan in keiner vernünftigen Variante existiert: ein Inventarmanagement. Das Sommerfest besitzt einiges an Material, aber das ist nicht inventarisiert. Wir haben keinen vernünftigen Überblick, was wir eigentlich alles haben. Vor allem bei größeren/kostenintensiveren Gegenständen wäre das schon interessant, hier auch eine Inventarisierung vorzunehmen. Weiterführend dann auch für den Verleih von Artikeln.

Nächster großer Punkt ist eine ToDo-Liste (Issue-Tracking). Es gibt eine Vielzahl an Aufgaben, die sich jedes Jahr wiederholen und leider passiert es doch immer wieder, dass einige Sachen vergessen werden und dann in letzter Sekunde noch erledigt werden. Hierzu soll ein Issue-Tracking Abhilfe schaffen, in dem alle Aktivitäten aus allen Ressorts verwaltet werden, samt Deadlines und Verantwortlichen. Sodass ein Blick in die Liste einen Aufschluss gibt, was momentan ansteht. Auch hier wieder ein “einmalig/jährlich”-Flag, um direkt einen Überblick über alle notwendigen Aufgaben zu bekommen. Das ganze sollte dann auch als Kanban-Board dargestellt werden.

Das ganze System soll auch unterschiedliche Berechtigungen abbilden. Dafür ist vor allem später das LDAP gedacht, wobei natürlich im Orga-Tool dann diese Berechtigungen auch umgesetzt werden müssen. Dabei ist auch angedacht allen Mitgliedern eines Ressorts direkt Zugriff auf das E-Mail-Postfach des Ressorts zu geben, also effektiv der Login durch das Orga-Tool. Und auch andere Passwörter könnten so im Tool hinterlegt werden, wobei noch zu klären ist, wie man das zumindest noch etwas absichern kann.

Um die alte Rundmail-Funktionalität abzulösen soll es auch die Möglichkeit geben, eine Mail an alle Mitglieder des Ressorts zu schicken. Das ließe sich auch kombinieren mit Ressort-News, also der Möglicheit Artikel zu verfassen um z.B. über aktuelle Aktivitäten im Ressort zu informieren. Dieser Punkt ist allerdings durch die Kommunikation in Slack etwas unwichtiger geworden. Lediglich für die Einladung zur Mitgliederversammlung wäre eine Rundmail-Funktionalität wünschenswert.

Zudem soll das Orga-Tool auch ein Archiv der Kommunikation sein, da wir die kostenlose Variante von Slack nutzen und somit nur die letzten 10.000 Nachrichten in Slack einsehen können.

[Update 1]
Ich hab bisher die Vision nie so detailliert aufgeschrieben, sondern immer eher in meinem Kopf mit mir rumgetragen. Daher ist das sicherlich weder vollständig noch abschließend. Und hier nun die erste Ergänzung:

Es soll auch eine Kommentarfunktion geben, sodass man z.B. ein Event kommentieren kann. Einen Überblick über alle Aktivitäten auf der Plattform gibt ein Activity-Feed, der alle Kommentare und ähnliches auflistet. Zusätzlich ist denkbar, auch pro Nutzer eine Sammlung von Aktivitäten zu seinen Inhalten anzubieten (so ‘ne Art Abonnieren-Funktion) für eigene Beiträge, wie man es von facebook kennt.
[/Update 1]

Eine eher im Spaß entstandende Idee ist die des Bullshit-Bingo. Hierbei sollten von den Nutzern Begriffe in eine Sammlung ergänzt werden, aus denen dann ein individuelles Bingofeld für jeden Nutzer generiert wird, was dieser dann interaktiv während des Treffens am Handy ausfüllen kann.

An Ideen mangelt es wahrlich nicht, leider aber an Zeit. Daher ist bisher erst ein sehr kleiner Teil dieser ziemlich umfangreichen Vision umgesetzt. Aber die Hoffnung stirbt zuletzt :)

Gut, bei Android ist das mit Boardmitteln aus irgendwelchen Gründen immer noch nicht möglich, aber mit ner kleinen Extra-App funktionierts … ^zurück
Hüst, so Leute wie ich … :D ^zurück

Moin!

Eike Broda — Wed, 20 Mar 2019 19:55:26 +0000

Ich bin Eike, Informatiker. Ich bastel’ immer mal wieder kleine Sachen, die teils schon recht nerdig sind, und will der Welt das nun mitteilen. Daher dieser Blog, der sehr spärlich gepflegt werden wird.

Vermutlich wird es zumeist auch ums Sommerfest gehen, da bin ich nämlich Ressortleiter für #digitales und somit für die komplette digitale Infrastruktur für die Organisation und Bremens größte Studentenparty verantwortlich. Digitale Infrastruktur klingt super fancy, tatsächlich ist es auch mehr als man so denkt. Für die Organisation steht inzwischen ein großes Portfolio an unterschiedlichen Anwendungen zur Verfügung: ein internes Diskussionsforum, ein Slack-Workspace, die Wenseite, Git-Repositories, E-Mails, das Bandbewerbungsportal tunefish, ein Tool zur Verwaltung der Schichten und noch ein paar kleine Anwendungen machen dort die Organisation einfacher.

Präferierte Programmiersprachen sind Python für Webgeschichten und Java für “andere” Sachen, aber je nach Projekt kann das durchaus auch mal abweichen. So basiert die Sommerfest-Webseite auf Jekyll aus dem Ruby-Bereich und einige ältere Anwendungen laufen noch auf PHP-Basis.

Dieser Blog basiert übrigens auf Hugo, momentan mit einem super-simplen Kiss-Theme. Ich wollte was, wo ich die Artikel in Markdown schreiben kann und was super-schnell ist. Da bot sich das dann an, auch wenn ich vorher nie was damit gemacht habe. Es ist noch einfacher und schneller als Jekyll. Nice.