Tag Archives: Campus WU

travel

Fotostrecke Campus WU

Zum Abschluss, und weil’s im Blog über den Altstandort nachgefragt wurde, gibt’s hier eine nicht ganz ernst gemeinte Fotostrecke zum neuen Campus WU.

Die Vorbilder finden sich hier.

fdg
TC/D1
xg
LC
fxg
EA
xgf
D4
fxg
D2
xg
AD/D3
z
D5
hacks

Von Algorithmen, Königreichen und Platzmangel

Obwohl ich mit dem vergangenen Post zum Thema Campus WU das Projekt für mich selbst abschließen wollte, muss ich hier noch einen Artikel nachschießen:

In der aktuellen Uni-Beilage von Der Standard komme ich als Vertreter der WU zu Wort. Der Artikel handelt vom Tool “more space”, das wir vorab zur Simulation der Gebäudeauslastung eingesetzt haben.

hgfd
“Der Standard”-Artikel über Raumeffizienz an den drei großen Wiener Universitäten.

tltr;

Unis verschwenden enorm viel Platz durch unflexible Stundenpläne und Besitzansprüche einzelner Mitarbeiter. An der WU läuft die Verteilung der Ressource Raum zentral und daher deutlich effizienter, als vermutlich anderswo.

IT project management

Campus WU: Drei Jahre in drei Minuten

Drei Jahre intensive (Projekt-)Arbeit, oder physikalisch ausgedrückt: Große Masse mal hoher Geschwindigkeit mal viel Weg.

“Man muß ins Gelingen verliebt sein, nicht ins Scheitern.”
Ernst Bloch

Door Signs

Über 200 Stück am gesamten Campus verteilt: Starten und aktualisieren sich über Netzwerk, gehen nachts schlafen, lesen Blinden die Belegung vor und kosten dabei ein Viertel der ursprünglichen Planung.

hj
61 der über 200 Displays vor Ort. Die angezeigte MAC-Adresse diente als Key bei der Inbetriebnahme.

Blogs dazu:

Self Service Terminals

Zehn Selbstbedienungsautomaten vor dem Study Service Center: Eine technische Herausforderung, barrierefrei, verbesserte Usability und – nach wahnsinnig stressiger Inbetriebnahme – inzwischen stabil.

bsfdb
Zwischenzeitlich haben tausende Studierende die Self Service Terminals im Library Center genutzt. (Sechs Terminals im Bild mittig; © Mathias August 2013)

Blogs dazu:

Final-Teilnahme beim Niederösterreichischen Innovationspreis.

Rooms

Dezentrale Raumbuchung für knapp 30.000 Benutzer_innen: Inhaltlich ist es Logistik pur samt dynamischer Lagerhaltung, Simulation, Statistik und passenden Visualisierungen. Rein technisch eine Herausforderung in JavaScript.

fff
Screenshot: User Interface der Raumbuchung für Studierende.

Blogs dazu:

Byte Bar und Leitsystem Terminals

fgfg fg
Die ByteBar- und Leitsystem-Terminals vor der Montage am Campus WU; Codename “Super-Toblerone”.

Surfstationen mit Login mittels berührungsloser Karte; Touchschirm, barrierefrei. Das Schwesterprojekt “Leitsystemterminal” dient zur Orientierung am Campus.

Blogs dazu:

API

gsg
Digital Signage Screens, die prominentesten Kunden unserer Lehrveranstaltungs-Daten API.

Viele unserer Daten sind – auch öffentlich – über Programmierschnittstellen verfügbar. So greifen alle hier beschriebenen Services auf dieselben Daten zurück, überall liest dieselbe Stimme Blinden vor, überall läuft dieselbe Logik, das Design ist gleich: managing complexity eines übergroßen Projekts eben.

Identmedien RFID

Eine Studierende holt sich einen Ausweis, verschließt ihre Sachen in einem der 3.600 Spindkasteln, bezahlt anschließend bargeldlos in der Mensa und öffnet einen gebuchten Projektraum: Keine Selbstverständlichkeit, läuft aber (immer besser).

Campus GIS

Geo-Informationssystem des Campus WU: Verortung von Personen und Organisationen, Suche nach POIs, Modellierung eines Routingnetzwerks zur Navigation, Flug einer Drohne für hochauflösende Luftbilder. Tool live: gis.wu.ac.at

Detaillierte Pläne, Suche, Routing bis hin zum Buch
Im Screenshot: Detaillierte Pläne der Regale zum Auffinden von Büchern in der Universitätsbibliothek.

Thanx + Uff!

Gerne würde ich hier behaupten, ich hätte das Alles programmiert, habe aber dann doch oft nur E-Mails geschrieben oder bin in endlosen Meetings gesessen. Ich musste langweilige Ausschreibungstexte querlesen, extern erdachte Konzepte ertragen, Kostenschätzungen durchs Haus schicken, Ideen verteidigen und am Widerstand Dritter scheitern sehen… Vier Befestigungsschrauben meiner Terminals kosteten mich so ein halbes Jahr Abstimmungsaufwand.

Als im Feuer getaufter Planerschlossertischlerdesignerentwickler kann ich nun verorten, kollaudieren, ausschreiben, beschaffen, eintakten, einbringen, einkippen, und Katzen hüten. Ich habe am Weg viele beeindruckende Menschen kennengelernt und dafür bin ich dankbar.

Es war ein Heidenspaß, ein Riesenstress und manchmal auch ein Mordsärger, vor allem aber war’s einzigartig und großartig. Wann und wo wird also der nächste Campus gebaut?

hacks

Last-minute door hack

Im Rahmen eines Großprojekts wird auf einige Türen und die Steuerbarkeit selbiger vergessen. Und schon sitzt man in einer großen Runde und diskutiert unter Zeit- und Kostendruck viele umständliche Lösungen. Was hier folgt, ist die wahrscheinlich größte Kosteneinsparung pro Zeiteinheit Softwareentwickler in der Geschichte des Häuslbauens – mein unvorstellbarer Kaffeekonsum bereits berücksichtigt… 

Man sollte meinen, eine Tür über einen Taster zu öffnen sei trivial. Doch was ist in einem Gebäude mit 1.500 Mitarbeitenden und 6.000 Türen schon trivial? Insbesondere wenn man nicht Türtaster auf jeden Schreibtisch stellen kann, und das Gebäude wenige Wochen vor Eröffnung ansich bereits fertig verkabelt sein sollte.

Elektriker öffnen Türen üblicherweise über potentialfreie Kontakte, also mit viel Kupfer zwischen Tastern und den Türen, aber eigentlich auch nur deswegen, weil die law of the instrument greift:

“if all you have is a hammer, everything looks like a nail”

Ich glaube, diesmal war dieses Gesetz auf meiner Seite, bzw. war ich eben in diesem Moment derjenige mit dem richtigen Hammer. Nailed it!

Türen via TCP/IP öffnen

Im Rahmen des Projekts rund um die elektronische Schließanlage haben wir uns eine Programmierschnittstelle (API) ausbedungen, welche unter anderem auch Türen öffnen soll. An einer Universität bestehen hierfür zahlreiche Anwendungsfälle, beispielsweise beim Öffnen von Lehrräumen während gebuchter Veranstaltungen. (An der “alten” WU habe ich das bereits mit einem heldenhaften reverse engineering des Kaba-Systems exos 9300 zustande gebracht. Aber damals gab’s diesen Blog noch nicht und ich hatte auch noch deutlich mehr Zeit zum Programmieren.)

Der richtige Client

Die Türöffnung via Klick auf einer Webseite auszulösen, drängt sich aus technischer Perspektive auf. Doch was ist mit Personen, die keinen  Rechner besitzen, oder gerade wieder mal auf das elendslange Einspielen diverser Windows Patches warten müssen? Eine Türöffnung sollte immerhin augenblicklich erfolgen.

Von einer vor der Tür stehenden Besucherin wird man angerufen, man ist also bereits am Telefon. Aus funktionaler Sicht liegt es folglich nahe, die Türöffnung auf dem Telefon zu bedienen. Cisco sei dank, gibt es für deren Call Manager eine umfangreiche Schnittstelle zur Steuerung des Telefons via XML.

ooo
Über XML eingespieltes Menü für mein Cisco Telefon.

Der Quellcode zur Darstellung des Menüs auf dem Foto:

<?xml version="1.0" encoding="utf-8"?>
<CiscoIPPhoneMenu>
  <Title>Bach Door Service</Title>
  <Prompt>Security FTW</Prompt>
  <MenuItem>
    <Name>IT Front Office</Name>
    <URL>https://bach.wu.ac.at/dd/playground/dooropener/open/1</URL>
  </MenuItem>
  <MenuItem>
    <Name>IT Back Office</Name>
    <URL>https://bach.wu.ac.at/dd/playground/dooropener/open/2</URL>
  </MenuItem>
</CiscoIPPhoneMenu>

gfg
Tür offen!

HTTP und Security

Sind alle Komponenten fertig, gilt es diese über HTTP zur Verfügung zu stellen. (Bevor noch jemand meckert: Telefone landen in einem eigenen VLAN – Türen gehen nur bei Anfragen aus dessen Adressbereich auf.)

e drfr fdw
Web-Interface zur Verwaltung von Telefonen, Türen, Personen und Organisationseinheiten. Die beiden letzteren werden automatisch aus SAP übernommen.
fdfdf
Bei Tastendruck am Telefon wird ein reverse lookup durchgeführt, der entsprechend zugeordnete Türen beim Telefon, bei der eingeloggten Benutzerin und deren Organisationseinheiten sucht. Zur Kontrolle gibt’s die Funktion auch im Web.

tltr;

Etwas Wagemut, acht Stunden Python-Hack und schon ist ein ganzes (Um-)Bauprojekt überflüssig.

travel

Abschied von der WU

Über den Campus WU wird dieser Tage viel berichtet.

Mit der Übersiedlung der WU an den neuen Standort blicke ich allerdings doch recht melancholisch auf meine WU zurück. Das UZA bleibt der mich prägende Ort aus Stahl, Glas und Asbest an dem ich studiert und gearbeitet habe. Zeit für einen Fotospaziergang durch verlassene Architektur, über die wohl auch in deren Entstehungsjahr 1981 viel berichtet wurde: 

hhh
Spittelau, Ausgang Wirtschaftsuniversität: Zwischen 2000 und 2007 soll dies mein täglicher Weg zum Studien- und späteren Arbeitsort sein. Vier Jahre davon zahle ich planmäßig für Fahrkarten der Wiener Linien, in den verbleibenden vier Jahren nur zwei Mal außerplanmäßig per Erlagschein: Betriebswirtschaft hautnah.
hhh
Maître Leherbs fünf 8×8 Meter großen Mosaiken sind die größten Fayence-Malereien des 20. Jahrhunderts. Schon bei der Immatrikulation stechen sie mir ins Auge. Den Großteil der Zeit hatte man sie allerdings recht gut hinter Bank- und Karrieremessen-Standeln versteckt.
hhh
Oktober 2000, Audimax: Ich sitze zwischen hunderten anderen auf der Stiege; Prof. Kasper eröffnet diese erste Veranstaltung meiner Studentenzeit sinngenmäß mit den Worten: “Aus feuerpolizeilichen Gründen darf ich diese Vorlesung nicht beginnen. Fangen wir also an!” Gerüchteweise wird das Parlament die WU als Ausweichquartier für deren eigene Renovierung besiedeln. Ab dann kann ich mit Recht behaupten, ich wäre zwischen 2000 und 2004 im Nationalrat gesessen.
hhh
Jänner 2002. Mein Einstieg ins Berufsleben und in die IT. Beim Bewerbungsgespräch: “Hast du Erfahrung mit Linux?” Und ich: “Ist das das mit dem Pinguin?”
hhh
Sommersemester 2003, Lokalszene: Nach meinem “Studienaufenthalt” in Thailand passieren mir knapp zwei Monate wilde Studentenzeit im Schnelldurchlauf. Danach bin ich wieder 40 wie ich das eben seit 16 bin. Im Bild: Die Hauptstiege der WU. Zwar hat sich die Damenmode geändert (im Zeitablauf: Arschgeweih, G-String, individuelles chinesisches Zeichen tätowiert, Thong), Alkohol wird aber nach wie vor getrunken (im Semesterablauf: billiger Glühwein, billiger Caipirinha).
hhh
2004 bis 2006, Hochlager I: Mit Blick auf die Hauptstiege sitz’ ich im Glaskasten und schreibe viel Verwaltungssoftware und wenig Diplomarbeit. Seit meinem Wechsel ins Hochlager II werde ich anscheinend problemlos vom Gerümpel vertreten.
hhh
Dezember 2005. Einen Stock über mir brennen Bibliothek und zwei Computerräume lichterloh. Ich stelle seelensruhig mein Auto währenddessen auf meinen Stammplatz in die Garage. Während das Auto löschwassernass noch trocknet werden bereits die Neubaupläne der WU verkündet.
hhh
2006. Ich wechsle ins Hochlager II und bin jetzt direkter Nachbar von Prof.Kasper (s. Audimax). Mit Blick auf Fernwärme und Kahlenberg entstehen Data Warehouse, Wissensbilanz und eine iPhone-App.
hhh
Frühjahr 2007. An diese Stelle lerne ich meine spätere Frau Isabella kennen. Meine mehrmals am Geländer angebrachten Gedenkschilder werden immer und immer wieder vom Reinigungspersonal entfernt.
hhh
2005-2013, jeweils Dienstag halb sechs: Lauftreffen (und danach Duschen) an der WU. Egal ob Vorbereitung für Halb- oder Richtigmarathon, oder nur Fitness und Plaudern: Laufen entlang des Donaukanals, vorbei an den Löwen und dem Donaufritzi in Nussdorf bis zu den Busreisentouristen nach Klosterneuburg, das alles wird’s so nie wieder spielen…
hacks

Designing APIs that work

With something around 20 systems that need interconnection, building APIs might currently be my main task at work. The systems involved range from access control, digital signage, kiosk and wayfinding terminals, CO2-sensors, facility management, resource allocation, geo-information to payment for printing or catering. In the context of an awfully huge project virtually everything needs data from somewhere else with schedules being extremely tight and vendor-side flexibility sometimes not being present at all. This simply means interface hell.

So be prepared for some lessons learned from someone who’s already made every possible mistake by himself:

One of the first public interfaces I wrote was a course data export for a mobile app, then running on iOS. The app developer and I decided on JSON using a list for the various attributes (title, location, time, etc.) of every course record:

[
  ["09W", "1985", "Wirtschaft im rechtlichen Kontext ", "H. 3.33 (B)", "UZA 1", "19:00", "21:00", 
    [
      [5803, "Lastname M."],
      [9651, "Lastname2 D."]
    ], "course", "20091212"
  ], 
  ...
]

As a matter of fact my first call came with two design failures attached: a badly chosen data structure and an unnecessary invention of something that was widely available anyway.

Use key-value pairs

First, using a list was a bad idea since position mattered and extending the interface immediately became a challenge since we quickly had 3.000 client-side installations out in the field. When using key-value pairs you retain the possibility of extending the data structure.

[
  {"semester": "09W",
   "course_id": "1985",
   "title": "Wirtschaft im rechtlichen Kontext ",
   ...
   }
]

Use wide-spread formats

Second, I suffered from the NIH anti-pattern since there was a decent exchange format available anyway: iCalendar. With a rewrite to the latter format data became usable even outside our app. People started importing personalized course lists into their calendars of choice.

Add metadata

After some time I realized that my course export was not only useful in its intended context but also in many other places: on digital signage screens for example. The latter project needed metdata so I added a timestamp and nested the payload inside the top level data structure.  

{"last_update": "2013-03-17T13:19:18",
  "courses":
    [
      {"semester": "09W",
       "course_id": "1985",
       "title": "Wirtschaft im rechtlichen Kontext ",
       ...
       }
    ]
}

Serialize

With calls available for courses, organizations, employees, publications, rooms, etc. in different flavours – usually search(), list() and get() – the overall structure soon became messy. Especially inconsistent naming started to be a pain when programming the server backend: employees had a "first_name" as members of organizational units whereas the same people carried a "firstName" when they authored publications.

While the key-value approach was a fine idea on the public side of my API the backend urgently needed refurbishment. I steadily moved my code to a more object-oriented approach which meant that I used Employee() objects rather than simple data structures. Nevertheless the API’s output consists of simple data types – so the magic of turning objects into JSON strings is mainly done by a serialize() method which every class must have:

class Employee(object):
    """Main Employee class"""
    ...
    
    def serialize(self):
        return {
	    'tid': self.tid,
	    'first_name': self.first_name,
	    'last_name': self.last_name,
            ...
        }

Add options

With more and more applications using the calls the clients became more demanding. For our wayfinding kiosk application I was asked to add pagination and custom sorting to some of the calls. I decided to provide an API-wide feature.
The result should look like this while sorting, limit, offset, etc. can be passed as arguments to the call (as key-value pairs rather than positional arguments of course!):

{"last_update": "2013-03-17T13:19:18",
  "offset": 100,
  "limit": 25,
  "sorting": {
      "fields": ["semester", "title"],
      "reverse": false
  },
  "courses":
    [
      {"semester": "09W",
       "course_id": "1985",
       "title": "Wirtschaft im rechtlichen Kontext ",
       ...
       }
    ]
}

Instead of painfully implementing pagination and sorting in a hundred different places I wrote a decorator that enables the functionality in a single place. The available sorting parameters have to be passed to the decorator since they differ from call to call.
@search_option_factory(set(['semester', 'title']))
def search_courses(self, value):
    """A sophisticated course search"""
    ...
        
    return courses

The decorator itself looks a bit complicated since passing arguments to decorators is a bit tricky. You actually have to write a function that handles the input and returns a decorator. Thanks to stackoverflow it’s not that difficult after all.
    def search_option_factory(sorting_set):
        """A decorator factory that handles generic options for calls.
        
        sorting_set: set that defines sortable fields
        
        according to Robert's spec:
        
        paging-objekt (struct) mit folgenden keys verwenden:
        - offset (null/int)
        - limit (null/int)
        - order (null/string)
        - desc (null/false/true)        
        """
        def search_decorator(method):
            
            def wrapper(self, value, options):

                # call the method
                recs = method(self, value)

                # count the recs
                count = len(recs)

                ## parse the options
                if not options:
                    options = {}
                
                sorting = options.get('sorting')
                if sorting:            
                    reverse = False
                    if options.has_key('reverse'):
                        r = options['reverse']
                        assert(isinstance(r, bool))
                        reverse = r
                
                    assert isinstance(sorting, list)
                    assert set(sorting).issubset(sorting_set)
                
                    sortator = ','.join(['d.%s' % x for x in sorting])
                    recs = sorted(recs, key=lambda d: (eval(sortator)), reverse=reverse)
                      
                
                offset = options.get('offset')
                if offset:
                    assert isinstance(offset, int)
                    recs = recs[offset:]
            
            
                limit = options.get('limit')
                if limit:
                    assert isinstance(limit, int)
                    recs = recs[:limit]
                
                return {
                    'count': count,
                    'limit': limit,
                    'offset': offset,
                    'payload': recs,
                    'created_at': datetime.datetime.now().isoformat()
                }
            
            return wrapper
        return search_decorator

hacks

Campus-Tetris revisited

Ich habe bereits über die Raumbuchung am Campus WU und eine damit verbundene Visualisierung der Belegung gebloggt. Hier in aller Kürze eine Visualisierung der Nachfrage nach Räumen.

Das Raumbuchungstool des Campus WU ist darauf ausgelegt, dass Mitarbeiter_innen wie Studierende – also etwa 30.000 Personen – selbständig und unbürokratisch Räume buchen können. Das dadurch drohende Chaos eines heillos belegten Gebäudes verhindern wir durch mehrere Parameter, wie etwa schrittweises Freigeben von Ressourcen, Speichern von Bedarfen in Raumgruppen anstatt in spezifischen Räumen, automatisierte Allokation, oder individuelle Berechtigungen. (Viele der hier genannten Dinge haben wir uns übrigens bei der Konkurrenz simulieren lassen.)

Anyway – wir sind nun seit genau einer Woche online und haben rund 8.000 Termine und somit bereits die Hälfte des kommenden Wintersemesters eingesammelt. Die Frage liegt also nahe, welche Räume (Raumgruppen) stark nachgefragt werden, und – am allerwichtigsten – wo etwaige Konflikte auftreten. Nach ein paar Stunden Python und Javascript kam dann mein Erfolgserlebnis, das ich auch gleich auf Twitter verewigen musste.

Programmieren mit d3.js (Data Driven Documents) macht also Spaß.

  d3.select("#applications")
    .append("g") 
      .attr("id", "application-frame")
    .selectAll("rect.application_frame")
    .data(data.slots)
    .enter()
    .append("rect")
      .attr("class", "application_frame")
      .attr("x", function(d) { return linear_scale(time_to_float(d.start) ) })
      .attr("y", function(d) { return POOL_POS[d.pool_id].y } )
      .attr("height", function(d) { return POOL_POS[d.pool_id].height } )
      .style("fill", function(d) { return occupancy_to_color(d.occupancy) })
      .transition()
        .attr("width",fifteen)
        .duration(500) // this is 1s
        .delay(function() { i = i +1; return i * 2; })         
  ; 

Ergebnis der Bastelarbeiten ist ein interaktives Diagramm, das mit dem Kalender-Widget oben gesteuert wird. Entlang der Tageszeit wird pro Raum-Pool (die Kapazität ist anhand der Fläche codiert) die Belegung inkl. der angefragten Termine visualisiert. Je stärker die Nachfrage, desto dunkler der Blauton. Liegt die Nachfrage über dem Angebot, wird das Blau zu einem gefährlichen Rot – hier gibt’s also dann etwas zu bereinigen.

sdsd
Visualisierung der angefragten und verfügbaren Kapazitäten pro Datum.

Das Ergebnis mit der traumhaft-schönen Animation auf YouTube. Das Diagramm ist erstaunlich responsive – immerhin werden mit jedem Klick eine Tabelle mit einer halben Million Einträge sechsmal durchsucht, der Tag in 60 Viertelstunden zerteilt und anschließend die Auslastung live berechnet.

Links

hacks

Die Tetris-Maschine

Der innerste Kern meiner Tätigkeit als Softwareentwickler ist die Erschaffung von Algorithmen. Dass das deutlich spannender sein kann als es klingt, will ich anhand eines aktuellen Projekts zeigen.

Beginnen wir mit einer Aufgabe: Gegeben ist die dargestellte Auslastung von vier Hörsälen. Es soll nun eine weitere Veranstaltung zwischen 13:00 und 14:00 (blau markiert) gebucht werden – welcher Raum ist nicht nur verfügbar, sondern auch optimal passend?

In welchem Raum soll der gewünschte Termin (13:00 bis 14:00) untergebracht werden?

Als Algorithmen werden in der Informatik Handlungsanweisungen zur Lösung eines Problems verstanden. Algorithmen können so etwa als Kochrezepte für Computerprogramme verstanden werden. Sie berechnen Manager-Boni, kümmern sich bei Word um die Rechtschreibkorrektur, twittern Aktienkurse oder – wie in meinem Fall – verhelfen der WU künftig zu einer optimierten Ausnutzung der Ressource Raum.

Algorithmisches Denken ist die Umkehrung von Schul-Mathematik. Beim Programmieren ist die Lösung bekannt, aber es gilt den Weg dorthin zu entdecken.

Das Teaching Center am Campus WU: Stählerner Schauplatz für Raumbuchungs-Tetris im XXL-Format. Mathias, 2012.

Jedenfalls: Bei unserem Re-Write der Raumverwaltung für den Campus WU sind wir mit einigen, höchst spannenden Anforderungen konfrontiert: Raumbuchungen sollen künftig automatisch und optimal durchgeführt werden, den Administratoren bleibt allerdings jedwede Flexibilität erhalten. Die Software kümmert sich dabei um Studien- wie Stundenpläne, um Verfügbarkeit der Lehrenden und “Extrawürschteln” ebenso, wie um Minimierung von Buchungslücken oder Reduktion unnötigen Reinigungsaufwands aufgrund zu vieler, “angepatzter” Hörsäle. Die Ressourcen sollen flexibel verfügbar sein (Stichwort dynamische Lagerhaltung), ein allzu häufiger Ortswechsel macht Studierende wie Lehrende aber wohl kaum glücklich.

Wir benötigen daher wieder einmal den “Do what I want“-Button:

       +-----------------+
       |                 |
       | DO WHAT I WANT  |
       |                 |
       +-----------------+
Button, der in jeder Software genau 
das tut, was der User will. 
(Grobkonzept)

Von der Idee zum Algorithmus

Die Aufgabenstellung lautet demnach:

  • Liefere für eine Serie von Terminen (z.B.: ein ganzes Semester) Buchungsvorschläge
  • innerhalb der angefragten Raumkategorie,
  • versuche dabei die gewünschten Zeiten zu erfüllen,
  • d.h. immer dieselbe Beginnzeit zu ermöglichen,
  • vermeide außerdem Raumwechsel,
  • aber vermeide noch viel mehr den Wechsel von Gebäuden.
  • Beachte, dass Buchungen nahtlos aufeinanderfolgen sollten.
  • Entstehen dennoch Lücken, so sind z.B.: 30 Minuten sehr schlecht, weil dieser Zeitraum sicher verloren ist,
  • 90 Minuten hingegen sind gar nicht so schlimm, weil ja noch etwas reinpassen könnte.
  • Bereits “angepatzte” Räume sind leeren vorzuziehen, weil dadurch der Reinigungsaufwand verkleinert wird.
ggg
Geistreiche Bilder vom Entstehungsprozess des Algorithmus. (…)

 

Die Grenzen der Berechenbarkeit

Ein naiver Lösungsansatz wäre nun, alle Möglichkeiten zu versuchen und die beste zu wählen. (Tatsächlich funktionieren viele Algorithmen nach diesem Prinzip.) In diesem Fall bekommen wir aber ein Problem mit der Dimension der Aufgabe:

Will etwa jemand an acht Montagen irgendwann zwischen 9:00 und 12:00 eine zweistündige Lehrveranstaltung abhalten, so ergeben sich (zu) viele Buchungsmöglichkeiten. Entlang eines 15-minütigen Rasters erhalten wir zunächst fünf mögliche Beginnzeiten (9:00, 9:15, 9:30, 9:45, 10:00). Diese fünf Beginnzeiten über rund 50 gleichwertige Seminarräume an acht Montagen ergeben acht mal fünf mal 50 – also zweitausend – Einzelmöglichkeiten. Die Berechnung der Kombinationsmöglichkeiten ergibt 15 Quintillionen [sic – 250hoch8 – eine 15 mit 18 Nullen]!

Wir reden allerdings nicht nur von einer Veranstaltung, sondern von knapp 4000 jährlich mit rund 35000 Einzelterminen – Tendenz Dank erweiterter Buchungsmöglichkeit für Mitarbeiter und Studierende stark steigend. Selbst wenn ein leistungsfähiger Rechner eine Milliarde Kombinationen pro Sekunde ausprobieren würde, wäre die erste Raumbuchung erst nach knapp 500 Jahren fertig…

Tetris

Glücklicherweise gibt es Tetris! Ähnlich wie bei den von oben fallenden Steinen kommen auch die Buchungswünsche Schritt für Schritt herein. Jede Buchung muss auf die jeweils aktuelle Belegung Rücksicht nehmen, kümmert sich aber nicht um das, was noch kommt. Genauso wie bei Tetris ist es auch bei Raumbuchungen sinnvoll, Lücken bestmöglich zu füllen, oder doch für passgenaue Steine in naher Zukunft frei zu halten.

Tetris-Klon von Nintendo: Dr. Mario. Aufgrund unseres akademischen Kontexts an der WU die wohl bessere Analogie.

Die Matrix

Tetris-Analogie hin oder her, noch besteht das Problem der zu vielen Lösungen. Manchmal hilft es, die Aufgabenstellung in kleine Teile zu trennen, das Problem zu abstrahieren, sich typische Situationen aber vor allem auch Grenzfälle (corner cases) zu überlegen.

Eine Terminserie zu unterschiedlichen Beginnzeiten, in Gebäuden und darin enthaltenen Räumen entspricht einer vierdimensionalen Matrix, so einer Art Excel-Tabelle, wo in jeder Zelle nochmal eine Tabelle enthalten ist. (Keine Sorge, so etwas kann auch ich mir nicht wirklich vorstellen.)

Die Einträge in dieser Matrix sind jedenfalls:

  • pro Termin
  • pro Beginnzeit
  • pro Gebäude
  • jede verfügbare Raumnummer
  • mit Bewertung der Passgenauigkeit

Die Passgenauigkeit beträgt 1, wenn der Raum einfach frei ist, 0 wenn er gebucht ist. Sollte ein Termin nahtlos reinpassen, erhöht sich der Wert über 1, bleiben Lücken, so bekommt der Raum Strafabzüge. Die Datenstruktur sieht früher oder später so aus:

{Termin1: {'12:00': {Gebaeude1: {Raum1: 0.47250000000000003, Raum2: 1.6}}},
 Termin2: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 1,
                           Raum2: 1,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin3: {'12:00': {Gebaeude1: {Raum1: 2, Raum2: 2}}},
 Termin4: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 2,
                           Raum2: 2,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin5: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 0.45,
                           Raum2: 0.3375,
                           Raum3: 1,
                           Raum4: 1}}},
 Termin6: {'12:00': {Gebaeude1: {Raum2: 0.45, Raum3: 1, Raum4: 1}}},
 Termin7: {'12:00': {Gebaeude2: {Raum5: 1},
               Gebaeude1: {Raum1: 1, Raum3: 1, Raum4: 1}}}}

Die optimale Buchung

Die beste Lösung findet man nun nicht durch stumpfsinniges Ausprobieren, sondern durch geschicktes Durchschreiten der Datenstruktur. Der Lösungsweg lautet:

FÜR jede Terminanfrage    
  FÜR jede Beginnzeit gereiht nach Häufigkeit terminunabhängig
    FÜR jedes Gebäude gereiht nach Häufigkeit in Beginnzeit
       FÜR jeden Raum gereiht nach Passgenauigkeit in Beginnzeit
         VERSUCHE zu buchen
         ODER gehe weiter

Die Lösung der eingangs gestellten Aufgabe lautet übrigens “Raum B”. Oder wenn Sie zufällig ein Algorithmus sind:

{1: {'12:00': {123456789: {66778801: 0.47250000000000003, 66778802: 1.6}}}}

Übrigens: Geschafft in 0.7 Sekunden anstatt von 500 Jahren.

tltr;

Raumbuchen ist wie Tetris-Spielen; Excel kennt zum Glück keine Tabellen in Zellen.

hacks

Kiosk-Terminal mit schnellem Login

Dem so genannten Octopus habe ich mich an dieser Stelle bereits ausgiebig gewidmet. Der von uns als Buckelwal bezeichnete Kiosk-Terminal kam bislang zu kurz. Hier also ein schnelles Update.

Der Anwendungsfall ist nicht neu: Im öffentlichen Bereich der WU Wirtschaftsuniversität Wien sollen Kiosk-Terminals schnellen und unkomplizierten Zugang zu Informationen, also dem Internet, sichern. Seit mehr als zehn Jahren gibt es mit der so genannten ByteBar bereits eine Lösung. Inzwischen macht sie vielleicht optisch nicht mehr allzu viel her – auf Seiten der Zuverlässigkeit und Wartungsarmut läuft das System allerdings beeindruckend vor sich hin.

ByteBar WU Wirtschaftsuniversität Wien.

Als ich mir gegen Ende 2010 das erste Mal Gedanken machte, was man am Baulichen und Haptischen verbessern könnte, fiel mein Blick auf die Suchmaschine bei Ikea. Diese vereint in durchdachter Schlichtheit und Pragmatik Features wie Stabilität, Touchscreen und/oder Tastatur, Kosteneffizienz, Servicierungskonzept, Sicherheit und Raumausnutzung.

Bei Ikea wissen die Designer was sie tun: Optimale Raumausnutzung, Schutz gegen Wagerl-Kollisionen, Kosteneffizienz. Mathias, Ikea Wien Süd (2010)

Mit dem schwedischen role model im Gepäck beauftragte ich 2011 einen Kiosk-Hersteller mit der Anfertigung eines Prototypen. Aus Designgründen entschieden wir, die Hardware hinter der Oberfläche verschwinden zu lassen, unterschiedliche Arbeitsplatzhöhen sollten außerdem unser Bekenntnis zu mehr Barrierefreiheit verdeutlichen.

Rendering unseres Prototypen: Unterschiedliche Arbeitsplatzhöhen, viel Karma für Design-Götter.

Nach Liefer-Verzögerungen und einigen Tests wurde der Prototyp Februar 2012 an der WU aufgestellt. Die Software läuft nach wie vor noch nicht so, wie wir uns das am Ende vorstellen. Aber Sinn und Zweck eines Prototypen ist ja eben der vorzeitige Erkenntnisgewinn.

Steht seit Februar 2012 an der WU für öffentliche Tests.

Öffentliches Internet versus die Abwehr anonymer Surfer

Der Großteil des studentischen Feedbacks auf Facebook drehte sich schon bald um die Haptik der Tastatur. Ich ahnte bis dato jedenfalls nicht, wie viel Emotion im Tastatur-Thema liegen kann. Nach einer Abstimmung unter den Studierenden fiel die Wahl schließlich auf eine (hygienische) Metalltastatur mit Trackpad.

Ende Juni veröffentlichte ich das Abstimmungsergebnis auf Facebook. Gleich die allererste Reaktionen sollte das Thema Browser/Software nochmal komplett drehen:

“Viel wichtiger wäre es wenn das ZID es endlich mal schaffen würde das man auf der WU eigenen (!) Homepage endlich die Suchfunktion nutzen könnte! Ich habe dass schön mehrmals angeregt bin bis jetzt aber immer auf taube Ohren gestoßen.”

Studierender auf Facebook

An der ByteBar erhält man beim Aufruf WU-fremder Seiten eine Fehlermeldung: Der Zugriff auf externe Seiten wird nämlich verhindert, um Surfzeiten zu begrenzen und somit Wartezeiten für andere zu verkürzen. Diese Maßnahme erachte ich allerdings aus zwei Gründen für höchst fraglich:

  1. Im Zeitalter von Web 2.0, Cloud und whatever liegen nunmal sehr viele nützliche Dinge nicht innerhalb der WU. Spätestens bei der outgesourcten Suche über Google – wie oben mokiert – wird die Sache peinlich.
  2. Die Begrenzung des Internetzugangs war vor zwölf Jahren sicher sinnvoll. Doch ist sie das dank Breitband und Smartphones noch immer?

Mein Vorschlag, Internet einfach “aufzudrehen”, fand jedenfalls keine Mehrheit. Ich kann die Bedenken nachvollziehen, dass dadurch jeder Fremde an die WU surfen kommen könnte – unangenehm wird das jedenfalls bei strafbaren Aktionen im Netz… Kurzum: Ein Login-Mechanismus musste her.

Python + WebKit + Studierendenausweis

Gemeinsam mit unserem kongenialen Hightech-Partner La Gentz war schnell die Idee geboren, den Studierendenausweis alternativ zur mühsamen Username/Passwort-Authentisierung  zu verwenden. Eine Authentisierung soll innerhalb kürzester Zeit erfolgen – das simple Hinhalten der MIFARE-Karte erfüllt diese Anforderung perfekt.

Außerdem entschieden wir uns, einen WebKit-basierten Browser from scratch zu implementieren. Das erspart die mühvolle Arbeit, den Browser gegen noch so kreative Usereingriffe abzusichern. Ein Login-Widget liegt semi-transparent über den Inhalten des Browserfensters und fordert zum Hinhalten der Karte auf. Aktuell überprüfen wir das UI noch auf seine Usability.

Details zur technischen Umsetzung finden sich im La Gentz Blog.

Fehlermeldung im unauthentisierten Betrieb. Das semi-transparente Widget lädt zum Einloggen via Karte oder Username/Passwort ein.

Nach dem Login ist unbegrenztes Surfen möglich. Ein Countdown visualisiert die verbleibende Zeit im Falle von Inaktivität.

Siehe da: Nach dem Login darf ich unbegrenzt surfen. Danach kann ich mich abmelden oder werde nach 1:30 Inaktivität automatisch rausgeschmissen.

Mit Ubuntu ist ein Betriebssystem ohne Wintendo-Krankheiten gefunden, LDAP bzw. JSON-RPC dienen zur Authentisierung. Demnächst folgt noch der Netzwerk-Boot (ähnlich den Door Displays).

Somit ist Websurfen künftig zufriendenstellend möglich, und wir brauchen keine Angst vor Internet-absaugenden Massen zu haben;-)

IT project management

IT-Outsourcing – heilige Kuh des Managements

Auf meinem Flug nach Mumbai sehe ich eine Dokumentation über den Bau des Londoner Aquatics Centre, dem Landmark der Olympischen Spiele 2012. Selbe Architektin, noch größere Dimensionen spielen sich bekanntlich derzeit am Campus WU ab. Angesichts dieser ehrfurchtgebietenden Superlativa drängt sich eine Frage auf, die ich in den vergangenen Monaten immer wieder gehört habe: “Warum wird die Campus-Software von der WU selbst und nicht von professionellen Anbietern entwickelt?”

Eigentlich sind es zwei Fragen, die hier gestellt werden:

  1. Warum greifen wir nicht auf Standard-Software zurück?
  2. Warum wird Individualsoftware nicht durch Externe entwickelt?

Eins vorweg: Natürlich verwenden (und vor allem integrieren) wir Standardsoftware. Softwareentwicklung wird bei uns in den unterschiedlichsten Konstellationen und natürlich auch von Externen durchgeführt. Aber wir entwickeln etwa mit der Raumbuchung, dem automatisiertem Schließsystem oder den digitalen Hörsaalanzeigen viele Kernthemen der IT am Campus aus gutem Grund selbst.

Kabeltassen im Gebäude W1E - hier fließt schon bald unsere Software durch die Leitung.

Um bei einer Metapher des Bauprojekts zu bleiben wirkt es so, als ob wir unsere eigenen Maschinen, unseren eigenen Stahl und unseren eigenen Beton herstellten. Was bei klassisch-produzierenden Unternehmen sich wohl kaum rechnen würde, ist in der Softwareentwicklung allerdings Normalität. Durch den Wegfall von Fixkosten (keine Stahlwerke notwendig) und die de-facto nicht gegebene Standardisierung habe ich bei jedem Teilprojekt die Möglichkeit, eine individuelle make-or-buy Entscheidung zu treffen.

Make or buy?

Für eine Eigenerstellung sprechen jedenfalls die Kosten: Um Urlaubs- und Fehlzeiten bereinigte Stundensätze interner Entwickler betragen rund ein Drittel jener von Externen. Dass bei Dienstleistern und Softwarehäusern ständig die richtigen Experten abrufbereit säßen, ist ein leider allzu weit verbreiteter Irrglaube. Hüben wie drüben muss man Einarbeitungszeiten, Schulungen und Irrwege letztlich bezahlen.

Kommunikation unter Kollegen ist jedenfalls einfacher, als Projektmanagement zwischen Unternehmen. Mit Pflichten- und Lastenheften, die Sales oder Legal jedoch nicht den Entwicklern dienen, mit juristischen Prozessen rund um Beschaffung oder service level agreements, mit Excel-bewaffneten Consultants, die eine zusätzliche Abstraktionsschicht zwischen Anforderung und Umsetzung einziehen, entwickeln sich IT-Projekte sehr schnell zu bürokratischen Meeting-Marathons. Auf diesem Weg entstandene Software tut am Ende oft ganz anderes, als es die Prozessdokumentation sagt, und die Kosten stehen schließlich in zweifelhaftem Verhältnis zum Ergebnis. Ich habe mehrfach die paradoxe Situation erlebt, dass ein schneller, interner Hack bereits fertig war, bevor noch ein Kick-Off stattfand. (…)

Gleichzeitig gibt es allerdings eine Reihe an IT-nahen Dienstleistungen, die sehr gut ausgelagert werden können: Betrieb von Hardware, Grafik-Design oder Dateneingabe sind Beispiele, wo ich kaum überlegen würde.

Immer wenn die technischen Anforderungen entweder niedrig oder extrem hoch sind, jedenfalls  aber wirklich nur wenn die Anforderungen der Benutzer klar sind, dann zahlt sich Outsourcing aus.

Denn dann sind Leistungen überschaubar und somit Preise verhandelbar, und man profitiert vom Spezialwissen der Experten. (Das Stacey Diagramm lässt sich also womöglich auch für make-or-buy Entscheidungen vergewaltigen.)

Die Standarsoft-Mär

Wäre die Diskussion über die Vorteile interner und externer Individualentwicklung nicht ohnehin hinfällig, würde man von vornherein auf Standardsoftware setzen? Nun, vieles, was bei Individualentwicklung zum Einsatz kommt, ist ohnehin standardisierte Software in Form von Betriebssystemen, Datenbanken, Frameworks und Libraries. Software zu entwickeln bedeutet zu einem großen Teil, derartig generell-anwendbare Bausteine zu einem individuell-leistungsfähigen System zu kombinieren.

Gleichzeitig ist vieles, was Standardsoftware heißt, fernab von Standardisierung, wie man sich das etwa bei einem Auto vom Fließband vorstellt. Auch wenn Banken, Airlines oder eben Universitäten Software der Big Player einsetzen, so passiert bei der Integration ins Unternehmen zwangsweise immer wieder dasselbe: Früher oder später enden die Möglichkeiten des Customizing, und Berater, Sub-Firmen oder interne Entwickler schreiben spezialisierte Programme, um das Ding zum Laufen zu bringen. Das bedeutet aber auch, dass die Abhängigkeit von einzelnen Personen auch bei Standardsoftware nicht geringer ist.

Business-IT ohne Abhängigkeit von einzelnen Schlüsselpersonen ist eine Mär!

Mit steigender Komplexität der Anforderungen wird es also zunehmend unwahrscheinlich, dass ein Anbieter genau das erfüllt, was ein ein Unternehmen benötigt. Das Resultat heißt bei Standardsoftware dann erst wieder Individualentwicklung.

Indien - Land der IT-Hotlines und heiligen Kühe. Mathias, Mumbai 2012.

Und hier schließt sich der Kreis, zu den oben gestellten Fragen. Ich genieße jetzt mal meine Tage in Indien – übrigens ein Land, wo mein Job aus genannten Gründen doch nicht so schnell hinwandern wird…