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: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), 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.

Grundlagenteil (Aspekte von Microservices und Event-getriebener Architektur)

In der fachlichen Grundlagenveranstaltung (5 ECTS) werden aufbauend auf dieser Erfahrung die architektonischen Grundlagen aufgearbeitet und reflektiert, um “Best Practices” zu erarbeiten. Dies umfasst Architektur-Prinzipien, aber 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.

Benotung (auf Basis von Punkten zwischen 0 und 3)

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.

Teilnote für den Praxisteil - Software-Entwicklung (Entwicklung eines Players)

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.

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.

Teilnote für den Grundlagenteil

Im Grundlagenteil bewerte ich nach Umfang und Qualität der implementierten Aspekte, 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 3 Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software nicht beherrscht. Selbst elementare Regeln und Prinzipien werden nicht eingehalten. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software nur ansatzweise beherrscht. Regeln und Prinzipien werden nur manchmal eingehalten. Die Grundlagen guten Software-oder System-Designs scheinen nach Durchsicht der Software weitgehend beherrscht. Regeln und Prinzipien werden meist eingehalten. 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. 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 ‘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

Anschließend wird eine Videoaufzeichnung der relevanten Teile zur Verfügung stehen, wenn jemand verhindert ist.

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 - 17:00: Workshop (Schwerpunkt folgt noch)

Workshop zur Veranstaltung. Agenda folgt noch. Ein Schwerpunkt wird "Testen mit Szenarien" sein

Ort des Workshops

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

Thu 23.05.2024, 10:00 - 17:00: Workshop (Schwerpunkt folgt noch)

Workshop zur Veranstaltung. Agenda folgt noch.

Ort des Workshops

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

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

Workshop zur Veranstaltung. Agenda folgt noch.

Ort des Workshops

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

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: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), 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: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), 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: 0504 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena), siehe auch detaillierte Wegbeschreibung.

Workshops "Grundlagenteil"

Thu 20.06.2024, 10: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.

Thu 04.07.2024, 10:00 - 17:00: Workshop (Schwerpunkt folgt noch)

Agenda folgt noch.

Ort des Workshops

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

Thu 11.07.2024, 10:00 - 17:00: Workshop (Schwerpunkt folgt noch)

Agenda folgt noch.

Ort des Workshops

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

Thu 18.07.2024, 10:00 - 17:00: Workshop (Schwerpunkt folgt noch)

Agenda folgt noch.

Ort des Workshops

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

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

Zum Abschluss der Gesamtveranstaltung werden die Ergebnisse vorgestellt. Genaue Agenda folgt 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