TU Wien:Distributed Systems Engineering VU (Weidl-Rektenwald)

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]

Inhalt[Bearbeiten]

ca. 6 VO-Einheiten rund um Software Engineering und Distributed Systems. "Offizieller" (=Folien-)Stoff ist etwas chaotisch und Wikipedia-lastig. Da der Vortragende aber nur in geringem Maß an der TU seine Moneten macht und stattdessen sehr stark in der freien Wirtschaft tätig ist, bereicht er den Vortrag ungemein mit praxisnahen Gschichteln, Tipps usw. Daher ist der Vortrag sehr zu empfehlen. Seine eigene Aussage (in etwa): Heute ist das Wikipedia-Zeitalter und es gibt nichts, was nicht in der Wikipedia steht, darum schreib ich nicht so viel auf die Folien (weil das könnts ihr eh selbst nachschauen) und erzähl stattdessen das, was nicht in der Wikipedia steht.

Das stimmt dann auch ziemlich. Berühmte Quotes (wiederum nur in etwa): "ACID, das war früher das Um und Auf, nichts ging ohne ACID und die Welt bestand aus ACID -- dann haben sich die Leute überlegt, ob wir das wirklich brauchen" (oder so in etwa). Weiters: "Der Bottom-Up-Approach - da teilt man das Problem in lauter kleine Subprobleme auf und jedes Team macht dann eine Lösung für das Subproblem. Und am Ende versucht man das alles zu integrieren. Und die Lösung lautet dann meistens, wir hauen das alles weg und kaufen SAP."

Außerdem gibt es parallel dazu eine Übung in 3er-Gruppen (siehe unten).

Ablauf[Bearbeiten]

ca. 6 VO-Einheiten; Übung in 3er Gruppen rund um Distributed Systems Engineering (mit vorgegebener Angabe); Übung mit "Projektstruktur".

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten]

  • Java-Kenntnisse nötig
  • Spring/Dropwizard und Maven-Kenntnisse von Vorteil (sonst geht viel Zeit damit drauf, das zu lernen, ihr kennts es eh vermutlich)
  • SS2015: MongoDB und Docker von Vorteil (aber auch problemlos nebenbei lernbar)
  • Lt. Prof. Verteilte Systeme (Vorlesung und Übung), das ist aber nicht essentiell
  • Spring MVC, Web, JSP, HTML, Angular etc.

Vortrag[Bearbeiten]

Eindeutig einer der besseren Vorträge. Sehr frei, sehr praxisorientiert. Allerdings oft ein bisschen Buzzword-lastig. Im Vortrag kommt selbst allerdings nur vergleichsweise wenig konkreter Stoff vor. Dennoch Empfehlung.

Übungen[Bearbeiten]

SS2012[Bearbeiten]

Im SS2012 ein relativ praxisnahes Projekt mit Spring MVC, Maven, JUnit etc. in 3 Komponenten entwickelt und auf der Cloud-Plattform cloudfoundry.com deployed werden musste. Die Übung ist mittelmäßig-wenig zeitaufwändig (bei etwas Geschick bzw. Kenntis der Technologien und guten Gruppenpartnern). Am Ende des Semesters gibt's dazu ein Abgabegespräch. Theoretisch stehen Tutoren zum Fragen im TUWEL zur Verfügung, aber im SS12 hat keiner eine einzige Frage gestellt.

Der Ablauf der Übung ist etwas projektmäßig, mit Projektplan, Architektur- und Designdokument, Wartungshandbuch, Code und Fazit-Dokument (letzteres pro Gruppenmitglied, der Rest pro Gruppe), dazu halt jeweils Abgabetermine und Punkte pro Deliverable.

SS2015[Bearbeiten]

Es war ein System zur Verwaltung von OP-Wartelisten zu implementieren. Mittlerweile wird nicht mehr oben genannte Cloud-Plattform verwendet, sondern es war eine Microservice Architektur zu entwickeln, davon verpflichtend:

  • mindestens zwei Microservices in Java (Vorschläge: Spring Boot, Dropwizard oder Spring Data MongoDB)
  • Hystrix
  • MongoDB (Geo-Suche)
  • Docker
  • REST-Schnittstelle am API-Gateway
  • mindestens 3 Unit Tests pro Service
  • mindestens ein Lasttest gegen das API-Gateway

Restliche Technologien und APIs waren frei zu wählen, in unserem Fall Node.js für weitere Microservices, Docker Compose für die Container-Verwaltung und Foundation/AngularJS für das Web-Frontend.

Ablauf der Übung immer noch gleich projektmässig wie oben beschrieben. Die zu erstellenden Dokumente sollten nicht unterschätzt werden, die kosten einiges an Zeit wenn man sie vollständig macht und alle Aspekte dokumentiert. Das soll den Charakter einer echten Projektentwicklung zeigen, bringt aber (imho) keinen Wissensgewinn.

Prüfung, Benotung[Bearbeiten]

VO-Prüfung und Abgabegespräch. Der Punkteschlüssel für die Übung ist sehr deutlich in der Angabe zu lesen. Prüfung ist tatsächlich relativ praxisnah. DH nicht "zähle alle Bullets von Folie X auf" sondern lt. Prof. z.B. "Beschreiben Sie Herausforderungen, die beim Bau von VSys entstehen können".

Prüfung SS2016: Fast dieselben Fragen wie im SS2015. Achtung! Auf der ersten Seite steh auch eine Frage ;)

SS18: Multiple choice test. Mit teils recht schwammingen Fragen und noch schwammigeren Antworten. 32 Fragen insgesamt, jede 1.25 Punkte (40 Punkte total), es ist mindestens eine Antwort von vier möglichen richtig, maximal sind alle Antwortmöglichkeiten richtig. Keine Teilpunkte aber auch keine Abzüge für falschbeantwortete Fragen. 60 Minuten zeit. Es war eher ein Buzzword Bingo und teils raten wie Fragen zu interpretieren sind. Fragen kamen auch zu Kubernetes, Hystrix (was nur in der Übung aber nicht in den Folien vorkommt).

Siehe Materialien!

Dauer der Zeugnisausstellung[Bearbeiten]

relativ lang (deutlich über 4 Wochen, ich glaub in etwa 6), allerdings kam die Note relativ pünktlich nach 4 Wochen. (Bzw. Benachrichtigung zur Einsichtnahme kam nach 4 Wochen; lustigerweise stand da die Note nicht dabei. Hab dem Prof dann aber eine Mail geschrieben und die Antwort war am nächsten Tag da.)

SS2015: Zeugnis zwei Wochen nach Prüfung/Abgabegespräch

Zeitaufwand[Bearbeiten]

OK. Da für die Prüfung nicht irrsinnig viel Stoff ist und viel vom Stoff schon woanders gehört wurde, muss man sich halt einige Dinge nochmal in Erinnerung rufen bzw. auf den speziellen Weidl-Rektenwald-Stil eingehen.

Die Übung kann von sehr wenig Zeitaufwand (mit Vorkenntnissen in den Technologien, speziell Spring MVC, JSP, Maven, CloudFoundry) bis moderat viel Aufwand (mit wenig Vorkenntnissen und schlechten Gruppenmitgliedern) reichen.

Unterlagen[Bearbeiten]

VO-Folien im TISS.

Tipps[Bearbeiten]

  • Angabe genau lesen, alle Pflichtpunkte erfüllen.
  • Implementierung nicht auf die letzten Wochen lassen. Im Juni ist sonst meist sehr viel los, und das Zusammenspiel der Services sowie das Zusammenfügen der APIs ist nicht zu unterschätzen. Besser auf eine Fertigstellung Ende Mai abzielen.

Verbesserungsvorschläge / Kritik[Bearbeiten]

  • Das Buzzword-Bingo kann manchmal nerven, wenn man nicht 100%ig von der supertollen Cloud und "wir sind jung und dynamisch und daher die tollsten" überzeugt ist.
  • Obige Kritik ist sicher richtig, es ist aber ein angenehmer Kontrast gegenüber anderen (teilweise verstaubt wirkenden) TU-LVAs, dass hier sehr aktuelle (gehypte) Technologien zum Einsatz kommen dürfen und sollen. Die große Wahlfreiheit ist dabei definitiv ein Plus.