Kontakt
stefan.bente[at]th-koeln.de
+49 2261 8196 6367
Discord Server
Prof. Bente Personal Zoom
Adresse
Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708 (Wegbeschreibung)
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail und ich weise Ihnen einen Termin zu.

WASP 1: Microservices und Event-getriebene Architektur (MEA), SS24

“Microservices und Event-getriebene Architekturen” ist eine Wahlspezialisierung 1 (15 ECTS) im 6. Semester des Informatik Bachelor an der TH Köln. Studierende werden umfassend in die Konzeption, Entwicklung und Betrieb moderner verteilter Software-Architekturen eingeführt. Der Fokus liegt auf der praktischen Umsetzung von Microservices, einer Architektur, die komplexe Anwendungen als Sammlung kleiner, unabhängiger Dienste strukturiert. Die Studierenden lernen, wie diese Dienste vorrangig asynchron (d.h. über Events) effizient kommunizieren, und wie sich eine solche event-getriebene Architektur auf die praktische Entwicklung auswirkt.

Studiengang und Modulbeschreibung
Informatik Bachelor
Zeitraum und zeitliche Organisation der Veranstaltung
04.04.2024 - 25.07.2024. Organisiert als Ganztages-Workshops (i.d.R. Donnerstags 10:00 - 17:00). Genaue Daten und Inhalte stehen weiter unten. Gehen Sie davon aus, dass Sie regelmäßig ca. 3 Tage die Woche für die Veranstaltung reservieren.
Ort der Veranstaltung
Die Veranstaltung findet in Präsenz statt. In Ausnahmefällen (aber nur wenn explizit für den Tag kommuniziert) weichen wir auf eine Remote-Option (Videokonferenz) aus. Wenn mehrere Räume angegeben sind, dann schauen schauen Sie bitte bei dem jeweiligen Zeitschlitz oder Workshoptag nach (siehe unten auf dieser Seite), welcher Raum an welchem Tag genutzt wird. Falls auf dieser Seite keine Angaben sind, prüfen Sie bitte die sonstigen Kommunikationkanäle für diese Veranstaltung (z.B. Discord).
Raum 1: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung
Raum 2: 1708 (Gebäude LC4 (Bibliotheksgebäude). Raum 1708 ist unser Labor-Großraumbüro, mit etwas Kreativ-Mobiliar und genügend Platz für kleine Workshops. Der Raum ist allerdings nur mit einem Transponder zugänglich. Deshalb kommen Sie bitte zu der Tür links vom Bibliothekseingang (erkennbar an dem Schild "Kriminalkommissariat" :-), ich werde Sie dort abholen Rufen Sie mich (+49 176 8072 2689) oder einen Kommilitonen per Handy an, falls Sie sich verspäten sollten.), siehe auch detaillierte Wegbeschreibung
Videokonferenz-Link: https://th-koeln.zoom-x.de/j/68619371496?pwd=MEVYQ2s5a21wWEF2MGRUbWlPZzA3Zz09 (nur in Ausnahmefällen und wenn explizit vorher für den Tag kommuniziert)
Anmeldung zur Veranstaltung
Bitte werden Sie Mitglied in diesem ILIAS/ILU-Kurs. Die Deadline ist 04.04.2024.
Maximale / minimale Teilnehmerzahl
Die maximale Teilnehmerzahl ist 12. Bei mehr Aufnahmeanträgen kann es ein Auswahlverfahren (durch ein kurzes, informelles Bewerbungsvideo, siehe unten) geben. Deadline für die Einreichung ist der 07.04.2024. Bei weniger als 5 Teilnehmer*innen kann die Veranstaltung leider nicht stattfinden.
Discord-Server für schnelle Kommunikation
Discord hat sich als sehr effektive Plattform für den Informationsaustausch, Diskussionen und Fragen an Lehrende/Betreuer:innen erwiesen. Deshalb sollten Sie dem ArchiLab-Discord-Server beitreten unter https://discord.gg/YYNYb5whU8. Navigieren Sie zum Channel #rollenzuweisung und klicken Sie auf mea und msd. Die entsprechenden Kanäle zur Veranstaltung werden anschließend für Sie freigeschaltet.
Youtube-Kanal
Für diese Veranstaltung sind Lehrvideos auf Youtube verfügbar. Abonnieren Sie dafür am besten den Kanal ArchiLab. Für die Videos zu dieser Veranstaltung gibt es eine Playlist. (Disclaimer - die Videos auf diesem Kanal sind nicht monetarisiert. Weder ich persönlich noch das Labor ArchiLab verdienen damit Geld. Wir nutzen YouTube vor allem deshalb, weil es für Studierende ein leicht zugänglicher Kanal ist. Außerdem bekommen wir als Labor an der TH Köln so auch Sichtbarkeit nach außen, was z.B. bei dem Einwerben von externen Gastvorträgen hilft.)

Inhalt

Learning Outcome

Die Wahlspezialisierung "Microservices und Event-getriebene Architekturen" konzentriert sich auf die praktische Anwendung von Kenntnissen zur Entwicklung und zum Betrieb moderner, verteilter Software-Architekturen. Wir verwenden aktuelle Technologien und Werkzeuge, die in der Entwicklung von Microservices Anwendung finden, um das Thema relevant und praxisnah zu behandeln.

Als Software-Entwickler:in kann ich Microservices mit Event-getriebenen Architektur entwerfen, implementieren und betreiben,

indem ich ...

  • die Prinzipien und Best Practices von Microservices verstehe und anwende,
  • asynchrone Kommunikationsmuster in einer event-getriebenen Architektur entwerfe und implementiere,
  • einen Player-Service in der Umgebung "The Microservice Dungeon" entwickele, der Roboterschwärme steuert,
  • wichtige architektonische Konzepte wie Skalierbarkeit, Fehlertoleranz und API-Dokumentation berücksichtige,
  • in kleinen Teams arbeite und dabei moderne Entwicklungs- und Deployment-Tools einsetze,
  • meine Entwicklungserfahrung reflektiere, um Best Practices und Architekturprinzipien für zukünftige Projekte abzuleite,

damit ich komplexe und skalierbare Microservice-basierte Softwaresysteme entwickeln und betreiben kann.

Aufteilung der Veranstaltung

Die Wahlspezialisierung “Microservices und Event-getriebene Architekturen” (MEA) ist eine 15 ECTS-Wahlspezialisierung im 6. Semester des Informatik-Bachelors an der TH Köln. Die Veranstaltung besteht aus zwei Teilen: einem Praxisteil (10 ECTS) und einem Grundlagenteil (5 ECTS).

Es gibt unabhängige Teilnoten für beide Veranstaltungsteile. Beide Teile sind eng miteinander verzahnt und bauen aufeinander auf, können aber auch einzeln belegt werden (und dann als WASP2-Formate anerkannt werden). Allerdings werde ich bei der Auswahl der Teilnehmer:innen diejenigen priorisieren, die beide Teile machen möchten - einfach wegen der genannten Verzahnung.

Praxisteil (Player-Implementierung im Microservice Dungeon)

Im Praxisteil (10 ECTS) entwickeln die Studierenden im der Umgebung The Microservice Dungeon einen Player-Service, der Roboterschwärme steuert, und bekommen so einen Einblick in die Besonderheiten dieser Architektur. Auf der obigen Dokumentationsseite gibt es einen Getting Started Guide, wo man z.B. nachlesen kann, wie man einen der bestehenden Templates (die sogenannten “Player-Skeletons”, verfügbar in 4 Programmiersprachen) nutzt, oder wie man die lokale Entwicklungsumgebung aufsetzt.

Beim Kickoff der Veranstaltung am 04.04.2024 werden wir eine Einführung in The Microservice Dungeon geben, mit Geschichte, Architektur, Roadmap, Infrastruktur, etc.

Die Arbeit am ersten Teil der Veranstaltung, dem Praxisteil, erfolgt im Zeitraum April bis Mitte Juni. Planen Sie bitte einen Aufwand von ca. 3 Tagen Vollzeit pro Woche ein. Das umfasst die unten gelisteten Workshop-Daten sowie die Zeit für die eigentliche Implementierung. Vieles an Arbeit findet “offline” statt, also nicht in den Workshops. Erfahrungsgemäß ist Discord für die Kommunikation untereinander und mit den Dungeon-“Supervisors” sehr hilfreich.

Sie können sich als Schwerpunkt entweder für die Entwicklung eines Players entscheiden, oder für die Arbeit an unserer Kubernetes-basierten Hosting-Infrastruktur (DevOps-Schwerpunkt). Bei der Player-Entwicklung muss jede:r Studierende einen eigenen Player schreiben (aber natürlich ist Austausch untereinander ausdrücklich erwünscht). Bei der Infrastruktur-Entwicklung arbeiten Sie in einem kleinen Team.

Die erste Projektphase endet mit einem dreitägigen Hackathon, bei die Player finalisiert werden, und wo das Deployment auf die Produktionsumgebung final getestet wird. Am letzten Tag gibt es einen “Codefight”, bei dem die Player gegeneinander antreten.

Teilnote für den Praxisteil - Playerentwicklung

Wie schon oben beschrieben, gibt es unabhängige Teilnoten für beide Veranstaltungsteile. Die Benotung erfolgt für beide Veranstaltungsteile auf der Basis von Teilkriterien, für die man jeweils zwischen 0 und 3 Punkte bekommen kann.

Für den Hauptteil der Teilnehmenden besteht der Praxisteil aus Entwicklung des eigenen Players, in Zusammenarbeit und Abstimmung mit anderen. Die Benotung erfolgt hier nach folgenden Schema.

Notenbestandteil Gewicht 0 Punkte 1 Punkt 2 Punkte 3 Punkte
Features, die der Player beherrscht 3 Player ist nicht lauffähig, und/oder es gibt keine sinnvollen und demofähigen Aktivitäten des Players, die über die zugelieferte Codebasis hinausgehen. Es gibt sinnvolle Aktivitäten des Players, die über die zugelieferte Codebasis hinausgehen. Ein Teil der wesentlichen Spiel-Features sind implementiert. Kaum Exceptions. Viele wesentlichen Spiel-Features implementiert. Keine Exceptions auf der Console.
Bewertung der Softwarequalität 2 Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software nicht beherrscht. Selbst elementare Regeln und Prinzipien werden nicht eingehalten. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software nur ansatzweise beherrscht. Regeln und Prinzipien werden nur manchmal eingehalten. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software weitgehend beherrscht. Regeln und Prinzipien werden meist eingehalten. Die Grundlagen guten Software-Designs aus Clean Code und Application Design scheinen nach Durchsicht der Software voll beherrscht. Regeln und Prinzipien werden vollständig eingehalten.
Automatisiertes Testing 1 Es gibt keinerlei automatisierte Tests. Es gibt ansatzweise automatisierte Tests, die aber nur einen kleinen Teil der Funktionalität abdecken. Ein systematischer Ansatz ist nicht zu sehen. Es gibt einen sinnvollen Satz von automatisierten Tests, die zumindest einen Teil der Funktionalität abdecken. Zwischen Unit- und Integrationstests wird nicht unterschieden. Fast alle Tests sind grün. Es gibt einen sinnvollen Satz von reinen Unit-Tests und darüber hinaus auch Integrations- oder E2E-Tests. Die Tests machen einen durchdachten, systematisch strukturierten Eindruck und decken die Funktionalität umfassend ab. Alle Tests sind grün.
Deployment und Codefight 1 Kein Deployment in die Produktivumgebung. Erste Maßnahmen fürs Deployment umgesetzt. Deployed in die Produktivumgebung, aber mit Problemen. Teilnahme am Codefight nicht vollständig möglich. Deployment in die Produktivumgebung. Erfolgreiche Teilnahme am Codefight.
Engagement und Eigeninitiative 2 Es ist keine Eigeninitiative zu beobachten; die wenigen Aktivitäten geschehen anscheinend nur auf Aufforderung durch Betreuer oder andere Teilnehmer:innen. In gewissen Bereichen ist Engagement und Eigeninitiative zu beobachten, was sich aber i.d.R. auf eigene Aktivitäten bezieht, nicht auf andere Teilnehmer:innen. Umgesetzte Aktivitäten geschehen aber meist nach Vorgaben. In einem Bereich ist ein deutliches Engagement sichtbar, oder eine gewisses Engagement in mehreren Bereichen (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) In mehreren Bereichen ist ein deutliches Engagement sichtbar (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.). Der/die Studierende ist eine der Leitfiguren der Veranstaltung.
Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt 1 Der/die Studierende hat sich so gut wie nicht an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war unterdurchschnittlich und nur bei wenigen Anlässen an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war durchschnittlich stark im Gesamt-Projekt sichtbar (Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen etc). Der/die Studierende ist außergewöhnlich stark im Gesamt-Projekt sichtbar gewesen, durch Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen und ähnlichem.

Insgesamt sind max. 30 Punkte zu erreichen. Eine 1,0 gibt es ab 27,5 Punkten, eine 4,0 ab 10 Punkten. Notenstufen dazwischen werden entsprechend interpoliert. 0 Punkte bei ‘Features, die der Player beherrscht’ oder bei ‘Bewertung der Softwarequalität’ führen automatisch zu einer 5,0. Alle Aspekte werden individuell bewertet.

Checkliste für den eigenen Player

Damit es am Schluss beim Code-Review der Player kein böses Erwachen gibt, hier eine Checkliste für den eigenen Player.

  • Features, die der Player beherrscht
  • Softwarequalität
    • Clean-Code-Regeln eingehalten?
    • SOLID-Prinzipien und DDD-Konventionen respektiert?
      • DDD: Module fachlich geschnitten?
      • SRP: keine Gott-Klassen und -Module?
      • DIP: keine zyklischen Abhängigkeiten?
    • Sinnvolle Architekturlösungen im Detail? (Z.B. parallele Eventverarbeitung, Idempotenz der Eventverarbeitung, “intelligente” Persistenzlösungen, etc., die dann auch dokumentiert sind)
  • Automatisiertes Testing
    • Sinnvollen Satz von reinen Unit-Tests vorhanden (nur Klassen- / POJO-Ebene, keine Mocks nötig)?
    • Integrations-Tests (brauchen lauffähige lokale Umgebung oder - noch besser - Mocks)
    • E2E-Tests mit Hilfe von Matias Testszenarien Framework?
    • Testabdeckung des Codes zufriedenstellend?
    • Alle Tests sind grün?
    • Sinnvolles Logging?
  • Dokumentation
    • Dokumentation der Funktionalität vorhanden in der README.md?
      • Welche Commands werden unterstützt?
      • Was sind die Grundgedanken der Strategie?
      • Wie bildet man die Map ab?
      • Wie weist man den Robotern die Aufgaben zu?
      • …
    • Besonderheiten der Architektur dokumentiert?
    • Javadoc für zentrale Klassen und Methoden?
  • Deployment
    • Dockerfile vorhanden?
    • Helmchart vorhanden und ok?
    • Lauffähig auf MiniKube?
    • Deployment in die Produktivumgebung erfolgreich?

Teilnote für den Praxisteil - DevOps (Arbeit an der Infrastruktur)

Das DevOps-Team wird aus 1-2 Personen bestehen, die zusammen mit der Administratorin des Microservice Dungeon die Infrastruktur weiterentwickeln und betreiben werden. Die Benotung folgt hier einem etwas anderen Schema.

Notenbestandteil Gewicht 0 Punkte 1 Punkt 2 Punkte 3 Punkte
Beitrag zur Erweiterung der Infrastruktur 4 Es ist kein nennenswerter Beitrag zur Weiterentwicklung der Infrastruktur festzustellen. Es ist nur ein geringer Beitrag zur Weiterentwicklung der Infrastruktur festzustellen, meist unter Anleitung und nach Aufforderung. Der Beitrag zur Weiterentwicklung ist sichtbar, und in großen Teilen eigenständig geplant und umgesetzt. Der Beitrag zur Weiterentwicklung signifikant und strahlt Weitsicht und Innovation aus.
Bewertung der Systemqualität 3 Die Grundlagen guten System-Designs scheinen nach Durchsicht nicht beherrscht. Selbst elementare Regeln und Prinzipien werden nicht eingehalten. Die Grundlagen guten System-Designs scheinen nach Durchsicht ansatzweise beherrscht. Regeln und Prinzipien werden nur manchmal eingehalten. Die Grundlagen guten System-Designs scheinen nach Durchsicht weitgehend beherrscht. Regeln und Prinzipien werden meist eingehalten. Die Grundlagen guten System-Designs scheinen nach Durchsicht voll beherrscht. Regeln und Prinzipien werden vollständig eingehalten.
Engagement und Eigeninitiative 2 Es ist keine Eigeninitiative zu beobachten; die wenigen Aktivitäten geschehen anscheinend nur auf Aufforderung durch Betreuer oder andere Teilnehmer:innen. In gewissen Bereichen ist Engagement und Eigeninitiative zu beobachten, was sich aber i.d.R. auf eigene Aktivitäten bezieht, nicht auf andere Teilnehmer:innen. Umgesetzte Aktivitäten geschehen aber meist nach Vorgaben. In einem Bereich ist ein deutliches Engagement sichtbar, oder eine gewisses Engagement in mehreren Bereichen (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) In mehreren Bereichen ist ein deutliches Engagement sichtbar (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.). Der/die Studierende ist eine der Leitfiguren der Veranstaltung.
Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt 1 Der/die Studierende hat sich so gut wie nicht an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war unterdurchschnittlich und nur bei wenigen Anlässen an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war durchschnittlich stark im Gesamt-Projekt sichtbar (Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen etc). Der/die Studierende ist außergewöhnlich stark im Gesamt-Projekt sichtbar gewesen, durch Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen und ähnlichem.

Insgesamt sind max. 30 Punkte zu erreichen. Eine 1,0 gibt es ab 27,5 Punkten, eine 4,0 ab 10 Punkten. Notenstufen dazwischen werden entsprechend interpoliert. 0 Punkte bei ‘Beitrag zur Erweiterung der Infrastruktur’ oder bei ‘Bewertung der Systemqualität’ führen automatisch zu einer 5,0. Alle Aspekte werden individuell bewertet.

Grundlagenteil (Aspekte von Microservices und Event-getriebener Architektur)

In der fachlichen Grundlagenveranstaltung (5 ECTS) als Bestandteil des WASP1 “Microservices und Event-getriebene Architektur” werden aufbauend auf der Praxiserfahrung im ersten Teil die architektonischen Grundlagen aufgearbeitet und reflektiert, um z.B. “Good Practices” zu erarbeiten, offene Fragen zu analysieren (und möglichst zu beantworten), und bestimmte Aspekte vertieft. Dies kann Architektur-Prinzipien umfassen, aber auch Aspekte wie Skalierbarkeit, Fehlertoleranz, API-Dokumentation, Organisation der Entwicklungsteams und weitere.

Die Aspekte werden wir gemeinsam im Workshop am Beginn der zweiten Veranstaltungsphase festlegen (Mitte Juni). Anders als im Praxisteil, wo die Arbeit am eigenen Player im Vordergrund steht, werden wir hier (in Feature Branches) an allen Teilen des Microservice Dungeon arbeiten, also auch den Core Services und der Infrastruktur.

Die Arbeit am zweiten Teil der Veranstaltung, dem Grundlagenteil, erfolgt im Zeitraum Juni bis Juli. Planen Sie bitte ebenfalls einen Aufwand von ca. 3 Tagen Vollzeit pro Woche ein. Auch hier finden viele Arbeiten “offline” statt, also nicht in den Workshops. In den Workshops werden wir in diesem Veranstaltungsteil die Ergebnisse der Arbeit reflektieren. Außerdem werde ich Ihnen Inhaltsimpulse zu verschiedenen Aspekten von Microservice-basierten Systemen geben, die asynchron (über Events) kommunizieren.

Die Veranstaltung endet mit einem Abschluss-Workshop, in dem die Ergebnisse der Arbeit präsentiert werden. Diese Präsentationen sind Teil der Benotung, neben der aktiven Mitarbeit in den Workshops und der Qualität des geschriebenen Codes. Anders als im Praxisteil werden Sie im Grundlagenteil in kleinen Teams arbeiten, die sich auf verschiedene Aspekte der Architektur fokussieren.

Themenspeicher für den Grundlagenteil

Auf der Themenspeicher-Seite sind mögliche Themen notiert, die Sie in einem kleinen Team bearbeiten können. Im Workshop am 04.07. machen wir eine Abstimmung, welche Themen Sie bearbeiten möchten. Die Abstimmung erfolgt über ILU, mit diesem Link.

Teilnote für den Grundlagenteil

Im Grundlagenteil bewerte ich nach Umfang und Qualität der untersuchten Aspekte (inklusive Konzept und Dokumentation), der Mitarbeit in den Workshops, und der Qualität der abschließenden Präsentation.

Notenbestandteil Gewicht 0 Punkte 1 Punkt 2 Punkte 3 Punkte
Qualität des implementierten Aspekts 4 Konzept und Dokumentation fehlen oder sind unbrauchbar. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software nicht beherrscht. Selbst elementare Regeln und Prinzipien werden nicht eingehalten. Konzept und Dokumentation sind nur ansatzweise geeignet. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software nur ansatzweise beherrscht. Regeln und Prinzipien werden nur manchmal eingehalten. Konzept und Dokumentation passen zur Aufgabenstellung, lassen aber Wünsche offen. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software weitgehend beherrscht. Regeln und Prinzipien werden meist eingehalten. Konzept und Dokumentation sind umfassend und auf den Punkt. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software voll beherrscht. Regeln und Prinzipien werden vollständig eingehalten.
Umfang des implementierten Aspekts 3 Es ist so gut wie nichts, oder nichts Sinnvolles, entstanden. Der Aspekt wurde implementiert, aber mit deutlich unterdurchschnittlichem Aufwand. Der Umfang der Implementierung erfüllt die Erwartungen. Der Umfang der Arbeiten übertrifft die Erwartungen an ein solches Projekt deutlich.
Präsentation (Demo, fachliche Aspekte, Reflektion) 1 Die Kernaspekte der Fragestellung sind nicht adäquat adressiert. Ein roter Faden ist nicht erkennbar. Eine Begründung fehlt weitgehend, oder ist unverständlich. Nur die wichtigsten Aspekte der Fragestellung sind adressiert. Trotz Inkonsistenzen, Auslassungen und Widersprüche ist ein roten Faden noch erkennbar. Einige Aspekte sind so gerade noch verständlich und nachvollziehbar begründet. Die Bearbeitung der Fragestellung ist meist konsistent. Viele wichtige Aspekte der Fragestellung sind adressiert. Es gibt Inkonsistenzen, Auslassungen und Widersprüche, im Ganzen ist es aber stimmig. Zumindest die Kernaspekte sind meist verständlich und nachvollziehbar begründet. Die Fragestellung ist in sich konsistent und stellt eine vollständige und umfassende Antwort für die beschriebene Aufgabenstellung dar. Alle Aspekte sind kurz, aber verständlich und nachvollziehbar begründet.
Engagement und Eigeninitiative 2 Es ist keine Eigeninitiative zu beobachten; die wenigen Aktivitäten geschehen anscheinend nur auf Aufforderung durch Betreuer oder andere Teilnehmer:innen. In gewissen Bereichen ist Engagement und Eigeninitiative zu beobachten, was sich aber i.d.R. auf eigene Aktivitäten bezieht, nicht auf andere Teilnehmer:innen. Umgesetzte Aktivitäten geschehen aber meist nach Vorgaben. In einem Bereich ist ein deutliches Engagement sichtbar, oder eine gewisses Engagement in mehreren Bereichen (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.) In mehreren Bereichen ist ein deutliches Engagement sichtbar (besondere Features, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.). Der/die Studierende ist eine der Leitfiguren der Veranstaltung.
Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt 1 Der/die Studierende hat sich so gut wie nicht an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war unterdurchschnittlich und nur bei wenigen Anlässen an Interaktionen im Gesamt-Projektteam beteiligt. Der/die Studierende war durchschnittlich stark im Gesamt-Projekt sichtbar (Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen etc). Der/die Studierende ist außergewöhnlich stark im Gesamt-Projekt sichtbar gewesen, durch Anleitung anderer, Hilfestellungen, Beiträgen zu fachlichen Diskussionen und ähnlichem.

Insgesamt sind max. 33 Punkte zu erreichen. Eine 1,0 gibt es ab 30,25 Punkten, eine 4,0 ab 11 Punkten. Notenstufen dazwischen werden entsprechend interpoliert. 0 Punkte bei ‘Qualität des implementierten Aspekts’ oder bei ‘Umfang des implementierten Aspekts’ führen automatisch zu einer 5,0. Die Aspekte ‘Engagement und Eigeninitiative’ und ‘Beteiligung an fachlichen Diskussionen und Interaktionen im Gesamtprojekt’ werden individuell bewertet, der Rest als Team-Note. Bei Teamnoten gehe ich von einem gleichmäßigen Beitrag aller Beteiligten aus; andernfalls behalte ich mir vor, den individuellen Anteil an den Team-Punkten abweichend zu bewerten.

Bewerbung

Es gibt insgesamt 12 Plätze, davon 1-2 Personen für einen “(Dev)Ops”-Schwerpunkt (also Arbeit an unserer Kubernetes-basiertes Hosting-Infrastruktur), der Rest für die Software-Entwicklung mit anschließendem Deployment.

Daher möchte ich Sie bitten, ein kurzes Video zu machen, in dem Sie erklären, was Sie an dem Modul reizt und warum Sie gern teilnehmen möchten (und bitte auch, ob Sie sich eher für den DevOps- oder SW-Entwicklungsschwerpunkt interessieren). Da wir eng und intensiv zusammenarbeiten werden, sollten diejenigen dabei sein, die überzeugend begründen können, dass sie sich für das Thema interessieren.

Die Videos müssen keinerlei technischen Anspruch haben - also bitte keine Slides o.ä. Es genügt, einfach das Smartphone zu nehmen und sich selbst zu filmen. Alternativ können Sie auch einfach das TH Köln Zoom aufrufen, loggen sich mit der campusId ein, und nehmen das Video auf die lokale Platte auf. Wichtig ist:

  • Max. 3 min Länge (danach schaue ich nicht weiter)
  • Bitte sagen Sie dazu, ob Sie sich eher für den DevOps- oder SW-Entwicklungsschwerpunkt interessieren.
  • Außerdem, ob Sie die gesamte Veranstaltung (also beide Teile, Praxis- und Grundlagenteil) machen möchten, oder nur einen der beiden Teile. Teilnehmer:innen, die beide Teile machen möchten, bekommen eine höhere Priorität, weil beide Teile aufeinander aufbauen.
  • Sie müssen nicht schon ganz viel “können” - ich wähle danach aus, wer überzeugend ausstrahlt, mit Freude an diesem Thema arbeiten zu wollen. Egal, wieviel Vorwissen Sie haben.
  • Das Video bitte so benennen: Nachname, Vorname.mp4
  • Danach laden Sie das bitte auf diesen einen anonymen Sciebo-Upload-Ordner hoch: https://th-koeln.sciebo.de/s/4fbWPxu8Sl7vMIn
  • Die Videos müssen bis 07.04.2024 eod eingereicht sein.

Sie können auch den Kickoff-Workshop am 04.04.2024 nutzen, um sich ein besseres Bild von der Veranstaltung zu machen und Fragen zu stellen, und dann erst das Video machen.

Was ist, wenn ich nicht zur Teilnahme ausgewählt werde?

Es gibt noch eine Anzahl weiterer Angebote für Wahlspezialisierungen. Schauen bitte in ILU nach, welche entsprechenden Kurse dort angelegt sind. Darüber hinaus hat der Prüfungsausschussvorsitzende (Prof. Dr. Gaida) eine Übersichtsseite zu WASP ins Intranet gestellt.

Workshops "Praxisteil"

Thu 04.04.2024, 10:00 - 17:00: Kickoff

Wir starten mit einer Einführung in die Veranstaltung und die Rahmenbedingungen. Außerdem gibt es eine inhaltliche Einführung. Danach geht es direkt mit der Teambildung und dem Aufsetzen Ihrer Umgebung los.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Ziel des Tages

Sie kennen die Rahmenbedingungen für MEA und können beginnen.

Die nachfolgenden Videos bieten zusätzliche Informationen zum Thema

Agenda

  • 10:00 - 10:45:  Organisatorisches
    • Zeitplan und Struktur das Praxis- und des Grundlagenteils
    • Youtube-Channel
    • Discord als präferiertes Kommunikationsforum
    • Einführung in die Aufgabenstellung im praktischen Teil
    • Benotung
  • 10:45 - 12:15:  Warmup und Motivation
    • Wie groß sind eigentlich große Software-Systeme?
    • Wie organisiert man die Arbeit an so großen Systemen?
    • Monolithen vs. Microservices
    • Was ist ein Microservice? Welche Vor- und Nachteile hat dieser Stil?
  • 12:15 - 13:15:  Mittagspause
  • 13:15 - 14:45:  Planspiel "Die Siedler von Softan"
  • 14:45 - 15:45:  Einführung in das Microservice-Dungeon-Projekt
    • Spielidee
    • Architektur
    • Core-Services
    • Getting Started für die Player-Entwicklung
  • 15:45 - 16:45:  Aufsetzen der Umgebung und Technologieentscheidungen / DevOps-Team-Absprachen
    • Einrichten der Entwicklungsumgebung (wir helfen)
    • Entscheidungen zu Programmiersprache, IDE, etc.
    • Parallel formiert sich das DevOps-Team und bespricht erste Schritte und Prioritäten
  • 16:45 - 17:00:  Wrap-Up und Fragen
    • Abschließend Wrap-Up und Ende des Workshop-Tages

Thu 11.04.2024, 10:00 - 13:00: Offene Fragen und Stand der Arbeiten

Dieser Workshop ist ausnahmsweise online (Termingründe Prof. Bente). Wir schalten uns zusammen, um offene Fragen zu klären und den Stand der Arbeiten zu besprechen. Außerdem gibt es ein Live-Coding zum "Getting Started".

Ort des Workshops

Videokonferenz-Link: https://th-koeln.zoom-x.de/j/68619371496?pwd=MEVYQ2s5a21wWEF2MGRUbWlPZzA3Zz09 .

Ziel des Tages

You're ready to go ;-)

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: r#F7=?v$).

Agenda

  • 10:00 - 11:30:  Organisatorisches, Fragen, DevOps-Team
    • Fragen zur Veranstaltung (für die, die beim Kickoff nicht dabei waren)
    • Wer hat Interesse am DevOps-Team?
  • 10:15 - 11:30:  Live-Coding "Getting Started"
    • Wie setze ich das DevEnv auf?
    • Wie fange ich an mit der Player-Entwicklung?
    • Wie kann ich weitere Features einbauen?

Thu 02.05.2024, 10:00 - 15:00: Workshop "Getting Started & Testing"

Wir besprechen den Stand nach den ersten Schritten, die Probleme dabei, und wie man am besten weitermacht. Außerdem schauen wir uns Testen mit Szenarien an, um den Player auch "offline" testen zu können. Die Inhalte können in diesem Foliensatz nachgelesen werden.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Agenda

  • 10:00 - 12:00:  Fragen und Feedback aus der Umfrage, und Strategie zum Weitermachen
    • Ich hatte eine Umfrage geschickt, um Feedback zu zu offenen Fragen einzusammeln.
    • Wir gehen zusammen durch das Feedback und diskutieren, wie wir weitermachen.
    • Ich schlage Ihnen eine Reihenfolge von Schritten vor, die Sie jetzt machen können.
  • 12:00 - 13:00:  Mittagspause
  • 13:00 - 14:00:  Testen mit Szenarien
    • Einführung in die verschiedenen Arten von (automatisierten) Tests
    • Testen mit Szenarien im Microservice Dungeon
  • 14:00 - 15:00:  Nächste Schritte
    • Nächste Schritte bei jedem Player
    • Organisatorisches

Thu 23.05.2024, 10:00 - 17:00: Workshop "Alles rund um Entwicklung und DevOps"

Wir beleuchten verschiedene Aspekte der Entwicklung und des Betriebs von Microservices. Dazu gehören vor allem DevOps als Konzept, mit Teilaspekten wie Continuous Integration, Deployment, Cluster-Struktur, aber auch Strategien zur Fehlersuche und -behebung. Die Inhalte können in diesem und diesem und diesem und diesem und diesem Foliensatz nachgelesen werden.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Agenda

  • 10:00 - 10:15:  Rundlauf - wer steht wo?
    • Kurzes Schlaglicht auf den Stand der Arbeiten
    • Themensammlung für weitergehende Diskussion, wenn nötig
  • 10:15 - 11:00:  Konzept "DevOps" und die CI-Pipeline (Matia Schumacher, Stefan Bente)
    • Was ist DevOps, und wozu ist das gut?
    • Einführung, was eine CI/CD-Pipeline eigentlich ist
    • Wie ist eine Konfigurationsdatei grob aufgebaut?
    • Workflow / Nutzen einer Pipeline
    • Vorstellung von common-ci-cd im MSD und deren Funktionsweise
    • Vorstellung der CI-Files im Java-Skeleton
  • 11:00 - 12:00:  DevOps konkret - Runner Configuration, Helmcharts, Minikube (Fijola Cyborski, Bernhard Sprenger, Omar Fourati)
    • Was sind Runner?
    • Aufsetzen der Runner-Configuration
    • Helmcharts und Kubernetes-Cluster
    • Minikube als lokale Cluster-Umgebung, und wie man das in der lokalen Entwicklung nutzen kann
  • 12:00 - 13:00:  Mittagspause
  • 13:00 - 14:00:  Umsetzung im eigenen Player (Fijola Cyborski, Bernhard Sprenger, Omar Fourati)
    • Das DevOps-Team hilft bei der Umsetzung der entsprechenden Configuration im eigenen Dev Env
    • Ziel ist, dass jeder am Ende der Session eine lauffähige CI-Pipeline hat, mit Runner-Configuration, Helmchart und Minikube zur lokalen Entwicklung
  • 14:00 - 14:30:  Fehlersuche und Debugging (Daniel Köllgen)
    • Fehlersuche und Debugging sind in verteilten Umgebungen weit komplexer als bei einer monolithischen Anwendung
    • Daniel gibt eine Einführung in die Strategien und Tools, so wie z.B. Logging und Tracing
  • 14:30 - 15:00:  Party erstellen, oder "wie spiele ich gegen mich selbst?" (Florian Lemmer)
    • Florian stellt sein Praxisprojekt vor
    • Mit Hilfe seiner Lösung kann man lokale Parties erstellen, die es erlauben, dass der eigene Player gegen sich selbst spielen kann, oder gegen einen unserer "Referenzplayer"
    • Damit sieht man frühzeitig, wo man in der Playerentwicklung steht
  • 15:00 - 15:30:  Nächste Schritte
    • Nächste Schritte
    • Zeitpuffer für weitergehende Diskussionen
    • Organisatorisches

Thu 06.06.2024, 10:00 - 11:30: Workshop (Schwerpunkt folgt noch)

Status der Player vor dem abschließenden Hackathon von Teil 1 der Veranstaltung

Ort des Workshops

Videokonferenz-Link: https://th-koeln.zoom-x.de/j/68619371496?pwd=MEVYQ2s5a21wWEF2MGRUbWlPZzA3Zz09 .

Agenda

  • 10:00 - 10:15:  Player Checklist für die Player-Entwicklung
    • Durchgehen der Checkliste und Klären von Fragen
    • Siehe Checkliste für den eigenen Player
  • 10:15 - 11:15:  Rundlauf - wer steht wo?
    • Ausführliche Vorstellung, wo jeder Player gerade steht
    • Klären von Fragen, Herausforderungen, Probleme
  • 11:15 - 11:30:  Themenspeicher für Teil 2 der Veranstaltung (Grundlagenteil mit inhaltlichen Schwerpunkten)

Tue 11.06.2024, 10:00 - 17:00: Abschluss-Hackathon Praxisteil, Tag 1

Am Schluss des ersten Veranstaltungsteils (Praxisteil) gibt es einen dreitägigen Hackathon. Hier wird der abschließende Codefight vorbereitet.

Ort des Workshops

Raum: 1708 (Gebäude LC4 (Bibliotheksgebäude). Raum 1708 ist unser Labor-Großraumbüro, mit etwas Kreativ-Mobiliar und genügend Platz für kleine Workshops. Der Raum ist allerdings nur mit einem Transponder zugänglich. Deshalb kommen Sie bitte zu der Tür links vom Bibliothekseingang (erkennbar an dem Schild "Kriminalkommissariat" :-), ich werde Sie dort abholen Rufen Sie mich (+49 176 8072 2689) oder einen Kommilitonen per Handy an, falls Sie sich verspäten sollten.), siehe auch detaillierte Wegbeschreibung.

Wed 12.06.2024, 10:00 - 17:00: Abschluss-Hackathon Praxisteil, Tag 2

Tag 2 des dreitägigen Hackathons.

Ort des Workshops

Raum: 1708 (Gebäude LC4 (Bibliotheksgebäude). Raum 1708 ist unser Labor-Großraumbüro, mit etwas Kreativ-Mobiliar und genügend Platz für kleine Workshops. Der Raum ist allerdings nur mit einem Transponder zugänglich. Deshalb kommen Sie bitte zu der Tür links vom Bibliothekseingang (erkennbar an dem Schild "Kriminalkommissariat" :-), ich werde Sie dort abholen Rufen Sie mich (+49 176 8072 2689) oder einen Kommilitonen per Handy an, falls Sie sich verspäten sollten.), siehe auch detaillierte Wegbeschreibung.

Thu 13.06.2024, 10:00 - 17:00: Abschluss-Hackathon Praxisteil, Tag 3 - Codefight

Abschließender Codefight, und dann Planung des zweiten Veranstaltungsteils (wer fokussiert auf welche weiterführenden Aspekte).

Ort des Workshops

Raum: 1708 (Gebäude LC4 (Bibliotheksgebäude). Raum 1708 ist unser Labor-Großraumbüro, mit etwas Kreativ-Mobiliar und genügend Platz für kleine Workshops. Der Raum ist allerdings nur mit einem Transponder zugänglich. Deshalb kommen Sie bitte zu der Tür links vom Bibliothekseingang (erkennbar an dem Schild "Kriminalkommissariat" :-), ich werde Sie dort abholen Rufen Sie mich (+49 176 8072 2689) oder einen Kommilitonen per Handy an, falls Sie sich verspäten sollten.), siehe auch detaillierte Wegbeschreibung.

Thu 20.06.2024, 10:00 - 12:00: Stand der Player-Entwicklung, und neuer Versuch Codefight

Wir arbeiten nochmal am Codefight, und tauschen uns aus zum Stand der Player-Entwicklung

Ort des Workshops

Videokonferenz-Link: https://th-koeln.zoom-x.de/j/68619371496?pwd=MEVYQ2s5a21wWEF2MGRUbWlPZzA3Zz09 .

Workshops "Grundlagenteil"

Thu 04.07.2024, 13:00 - 17:00: Kickoff Grundlagenteil

Erster Workshoptag des Grundlagenteils. Genaue Agenda folgt noch. Wir werden die Themen für den Grundlagenteil festlegen und Teams zur Bearbeitung bilden.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Agenda

  • 13:00 - 13:45:  Rundlauf - wer steht wo?
    • Vorstellung, wo jeder Player gerade steht
    • Klären von Fragen, Herausforderungen, Probleme
  • 13:45 - 14:45:  Start in den Grundlagenteil mit Diskussion des Themenspeichers
  • 14:45 - 16:15:  Team-Building und Abstimmung "wer macht was"
    • Bildung von Teams für die Bearbeitung der Themen
    • Ausformulierung und Planung des Vorgehens in den Teilteams
    • Jedes Teilteam stellt kurz vor, was es vorhat
  • 16:15 - 16:30:  Nächste Schritte und Abschluss

Thu 11.07.2024, 13:00 - 16:00: Vorstellung des Vorgehens in den Teams

Die einzelnen Teams stellen ihre Planung für das Vorgehen vor und diskutieren offene Fragen.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Agenda

  • 13:00 - 13:15:  Organisatorisches
    • Weitere Terminplanung der Veranstaltung
  • 13:15 - 13:45:  (A2) Real Time MSD
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 13:45 - 14:15:  (A3) Event Authorization in Kafka/Redpanda
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 14:15 - 14:45:  (A5) Dashboard als Microfrontend
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 14:45 - 15:00:  (P1) Bibliotheken für Player Health Checks
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 15:00 - 15:15:  (P2) Pluggable Strategy und typische Strategy-Patterns
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 15:15 - 15:45:  (P3) Besseres Player-Dev-Env
    • Vorstellung Recherche & Planung
    • Diskussion, offene Fragen
  • 15:45 - 16:00:  Abschluss und nächste Schritte

Thu 01.08.2024, 10:00 - 17:00: Thematischer Workshop zu Grundsatzthemen

In diesem Workshop werden wir Aspekte besprechen, die beim Bearbeiten der Grundlagen-Themen in den Teams hochkommen. Ich frage diese Themen vorher per Umfrage ab und bereite dann entsprechende Inhalte vor. Genaue Agenda folgt, wenn die Themen klar sind.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Thu 05.09.2024, 10:00 - 12:00: Remote-Treffen zur Vorbereitung der Abschlussveranstaltun

Kurzer Rundlauf zum Stand bei den Teams, Gelegenheit für Fragen und Organisatorisches zur Abschlussveranstaltung.

Ort des Workshops

Videokonferenz-Link: https://th-koeln.zoom-x.de/j/68619371496?pwd=MEVYQ2s5a21wWEF2MGRUbWlPZzA3Zz09 .

Thu 12.09.2024, 10:00 - 17:00: Abschluss-Workshop mit Vorträgen zu den Resultaten

Zum Abschluss der Gesamtveranstaltung werden die Ergebnisse vorgestellt. Außerdem machen wir nochmal einen Codefight. Uhrzeiten folgen noch.

Ort des Workshops

Raum: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Bildquellen

  • Banner: Generiert mit Dall-E
  • The Microservice Dungeon: © ArchiLab, TH Köln, 2021
  • Benotung: Generiert mit Dall-E