In der Mache: Mahlowat V2

Im letzten Jahr gab es zur Studierendenparlamentswahl an der Uni Bonn erstmals den sogenannten “Wahl-O-Man”, der ein lokaler Wahl-O-Mat-Klon ist. Dieses Angebot des formidablen studentischen Magazins akut habe damals ich implementiert.

Auch in diesem Jahr wird die akut wieder einen Wahl-O-Man anbieten. Bereits jetzt möchte ich eine bestimmte Hochschulgruppe darauf hinweisen, dass ich lediglich für die technische Umsetzung des Wahl-O-Man verantwortlich bin, inhaltlich jedoch gar nichts damit zu tun habe 😉

Für dieses Jahr bin ich dabei, den “Mahlowat”, wie ich die zugrunde liegende Anwendung benannt habe, einmal komplett zu überarbeiten. Größte Neuerung wird sein, dass die zur Wahl antretenden Listen ihre Antworten nun direkt in ein Webformular eintragen dürfen – die manuelle Übertragung der Antworten aus diversen Textdokumenten in den Wahl-O-Man war im letzten Jahr das Nervigste an der ganzen Aktion.

Außerdem wurde durch ein wenig JavaScript-Hexerei umgesetzt, dass nicht mehr jede zu beantwortende These einzeln vom Server geladen werden muss, sondern alles auf einer einzelnen Seite geschieht. Die Anwendung sollte dadurch erheblich schneller sein und deutlich weniger Frustpotenzial bieten. Dennoch kann per Sprungmarke1 immer noch direkt auf einzelne Thesen verlinkt werden.

Eine große Neuerung gibt es noch beim Teilen des Wahl-O-Man-Ergebnisses: Es ist jetzt möglich, nur das Balkendiagramm in sozialen Medien zu teilen, ohne dabei direkt die eigenen Antworten zu den Thesen zu verraten. Hierzu wird das persönliche Ergebnis auf dem Server gespeichert und anhand einer eindeutigen ID identifiziert. Die geteilte Ergebnisseite enthält keine Hinweise mehr auf die gegebenen Antworten. In bestimmten Fällen ist es allerdings trotzdem möglich, aus der Übereinstimmung mit den einzelnen Listen die gegebenen Antworten zu berechnen.

Sind Sie sicher? Der Mahlowat fragt nach.

“Sind Sie sicher?” Der Mahlowat fragt nach.

Wer nicht möchte, dass seine/ihre Antworten gespeichert werden, hat nach der Bewertung aller Thesen die Möglichkeit, auf die Speicherung zu verzichten. Dann gibt es allerdings auch keine Möglichkeit, das eigene Ergebnis auf die oben beschriebene Weise zu teilen, sondern der Share-Link enthält wie bislang die eigenen Antworten in kodierter Form.

Damit nicht etwa die Server-Logs über URL-Parameter die gewählten Antworten verraten, wurde auch die Navigation komplett überarbeitet. Das hat die folgende, lustige Konstruktion zur Übergabe von Daten zum Ergebnis:

Beim Klick auf einen Link zu einer Spezialseite wird per JavaScript ein Formular in die Seite eingefügt, das als Felder die zu übertragenden Werte enthält und als action die Zielseite. Dieses Formular wird dann sofort abgesendet und die Zielseite erhält die gewünschten Werte. Da die Werte nur als POST-Parameter hin- und hergeschickt werden, tauchen sie in der Zugriffslogdatei eines handelsüblichen Apache-Servers nicht auf.

Wird also auswählt, dass die Ergebnisse nicht gespeichert werden sollen, dann werden sie auch nicht irgendwo gespeichert.

Sobald der Mahlowat fertig überarbeitet ist, wird er wieder auf GitHub zur Verfügung gestellt.

  1. Dat is dat Dingen mit dem # ↩

Maps

Wer ein Android-Gerät mit sich herumträgt, schickt in mehr oder weniger regelmäßigen Abständen Informationen über den eigenen Standort an Google1.

In einem Tool namens “Google Standortverlauf” kann man sich die vergangenen Standorte seiner Mobilgeräte netterweise hübsch aufbereitet anzeigen lassen. Außerdem kann man die Standorte als kml-Datei exportieren.

Was könnte man damit alles machen? In meinem Artikel Nachts in Bonn hatte ich bereits die zurückgelegte Wegstrecke aus dem Standortverlauf exportiert und in einer OpenStreetMap-Karte dargestellt2.

Nun wollte ich etwas leicht anderes machen: Die innerhalb eines Monats erfassten Standorte und Bewegungen dynamisch auf einer Karte darstellen. Eine zweiminütige Internetrecherche brachte kein Tool zum Vorschein, das das konnte, was ich mir vorstellte. Außerdem macht alles viel mehr Spaß, wenn man es selbst gemacht hat.

Ich habe mir also ein Python-Skript gebastelt, das aus einer kml-Datei Zeitstempel und Standorte ausliest, diese nach Tagen, Stunden und Viertelstunden clustert und dann sukzessive auf eine vorgegebene Karte malt.

Diese 2784 Einzelkarten habe ich mit avconv in ein Video zusammengeführt. Für den Januar 2013 sieht das dann beispielsweise so aus wie im folgenden Video 3.

Es ist faszinierend zu sehen, wie stark die Frequenz der Datenpunkte schwankt: Mal ist die gesamte Straßenbahnlinienführung erkennbar, mal springt der Standort ohne bestimmtes Muster von einem Punkt zum anderen. Auch die fehlerhaften Standorte sind teilweise sehr lustig anzusehen, wenn sich z. B. plötzlich Strahlenbündel bilden. Und sooo oft habe ich auch noch nicht im Rhein gebadet.

Generell lässt sich aus dem Standortverlauf ein relativ gutes Abbild des Lebens der verfolgten Person rekonstruieren. Deshalb habe ich auch einen zwei Jahre alten Ausschnitt genommen. Ein Video aus Daten von 2014 sieht in einigen relevaten Punkten bereits etwas anders aus.

Das Python-Skript zum Übertragen der Pfade auf die Karte gibt es hier ausnahmsweise mal nicht, das ist nämlich noch sehr quick-and-dirty.

Notiz an mich selbst: Bilder und Musik mit avconv zu einem Video machen

avconv -r 10 -start_number 60 -i movie-%d.jpg -b:v 1000k -i music_file.mp3 -strict experimental output.mp4
  1. Sofern man nicht alle Standortdienste deaktiviert hat ↩
  2. Wie ich eben sehe, klappt die Einbindung der Karte dort irgendwie nicht mehr. Timing! ↩
  3. Hinweis: Die Tage und Uhrzeiten entsprechen nicht den realen Zeiten ↩