Microservice Architectures (MSA), WS23

Microservices sind ein Architekturstil, der die Entwicklung großer Softwaresysteme in weitgehend autarken Teams ermöglich. In diesem Kurs lernen Sie die wichtigsten Konzepte dazu kennen. Innerhalb eines relativ großen Projekts setzen Sie selbst Aspekte synchroner und asynchroner Kommunikation um.

Studiengang und Modulbeschreibung

Code & Context (Bachelor) (siehe auch Modulbeschreibung auf der Studiengangs-Seite)

Zeitraum und zeitliche Organisation der Veranstaltung

18.12.2023 - 12.01.2024. Organisiert als Blockkurs mit definierten Präsenzzeiten. Siehe unten für die genauen Daten.

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: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28)

Videokonferenz-Link: https://th-koeln.zoom-x.de/j/61363685608?pwd=VnZFWjh3dnMzRHVyUU4xeVFlcUFpdz09 (nur in Ausnahmefällen und wenn explizit vorher für den Tag kommuniziert)

ILIAS/ILU-Kurs zur Veranstaltung

https://ilias.th-koeln.de/ilias.php?ref_id=2122372&cmdClass=ilrepositorygui&cmdNode=wc&baseClass=ilrepositorygui

Miro Board für Gruppenarbeiten, Notizen und Modellieren während des Kurses

Im Kurs können Sie dieses Board nutzen.

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 coco. 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
• Organisation der Veranstaltung
  • Präsenz vs. Remote
• Praktischer Teil (Coding)
  • Teams für praktischen Teil
  • Aufgaben im praktischen Teil
  • Technologiefreiheit
  • Abschlussreflektion
• Benotung
  • Anteil des individuellen Beitrags zur Teamleistung
• Literatur
• Workshops
  • Mon 18.12.2023, 10:00 - 16:00: Kickoff
  • Tue 19.12.2023, 10:00 - 16:00: DevEnv-Setup und Loslegen mit dem praktischen Teil
  • Wed 20.12.2023: Selbstlerntag
  • Thu 21.12.2023, 10:00 - 16:00: MSA-Workshop
  • Fri 22.12.2023, 10:00 - 11:45: MSA-Workshop
  • Mon 08.01.2024, 10:00 - 16:00: Recap aus der Zeit zwischen den beiden Kurswochen, und Coding
  • Tue 09.01.2024, 10:00 - 16:00: Deployment des eigenen Players
  • Wed 10.01.2024: Selbstlerntag
  • Thu 11.01.2024, 10:00 - 16:00: Codefight und Vorbereitung der End-Präsentation am Freitag
  • Fri 12.01.2024, 10:00 - 15:00: Abschlusspräsentation und Retro

Learning Outcome

Als Software-Entwickler:in kann ich an großen Software-Systemen mitarbeiten,

indem ich ...

• die Fachlichkeit der Anwendung auf Basis von Dokumentation und Nachfragen verstehe,
• Aufbau und Begründung einer Microservice-Architektur mit synchroner und asynchroner Kommunikation nachvollziehen kann,
• einen eigenen Service mit Hilfe von Standard-Technologie umsetze,
• mein Vorgehen reflektiere und anderen beschreibe,

damit ich in beruflichen Situationen an großen digitale Produkten mit einem komplexen, verteilten Backend mitentwickeln kann.

Organisation der Veranstaltung

Microservice Architectures (MSA) ist eine Blockveranstaltung in Code & Context. Es wird folgende Struktur geben:

• Die Tage sind als Workshop angelegt und gehen von 10:00 bis 16:00…17:00, mit einer Mittagspause, die wir je nach Tages-Agenda aushandeln.
  • Ich versuche, jeweils immer jede Stunde 5 min Pause einzuhalten. Sollte es mir durchgehen, erinnern Sie mich bitte daran.
  • Die Präsenz-Workshops werden vermutlich etwas länger als 16:00 gehen - um 17:00 ist dann aber sicher Schluss. Dafür sind die Remote-Workshops tendenziell kürzer und lassen mehr Freiraum für individuelles Arbeiten.
  • Agenda und Uhrzeiten sind immer ungefähre Angaben. Wir werden spontan anpassen, wenn es schneller geht, oder mehr Zeit braucht, oder viele Fragen auftauchen, etc. Wenn es sinnvoll ist, werde ich auch spontan Inhalte tauschen, Inhaltsimpulse weglassen oder einschieben.
• Die Workshops bestehen aus Inhaltsimpulsen, selbstständigen praktischen (Programmier- und Modellier-)Übungen und Gruppenreflektionen.
• Einige Inhalte der Veranstaltung sind als Lehrvideos verfügbar. Nutzen Sie das gern als zusätzliche Information. Siehe auch Zeitplan mit nach Workshoptagen aufgeschlüsselten Inhalten,
  dort sind die Videos direkt verlinkt.
• Der Mittwoch ist als Selbstlern-Tag konzipiert. An diesem Tag gibt es kein Workshop-Programm.
• Ein Feedback ist auch außerhalb der Workshop-Zeiten möglich, bevorzugt über Discord (siehe oben).

Präsenz vs. Remote

Dies ist eine hybride Veranstaltung in dem Sinne, dass sich Präsenz- und Remote-Veranstaltungen abwechseln. WICHTIG: Bei Krankheitssymptomen bleiben Sie BITTE zu Hause! Alle Inhaltsimpulse werde ich aufzeichnen und als Recording zur Verfügung stellen. Nur Diskussionen und Präsenz-Aktionen wie das Event-Storming machen keinen Sinn als Aufzeichnung. Stand heute gibt es folgende Verteilung von Präsenz und Online:

Mo 18.12.	Di 19.12.	Do 21.12.	Fr 22.12.	Mo 12.12.	Di 13.12.	Do 15.12.	Fr 16.12.
Präsenz	Präsenz	(tbd)	(tbd)	Präsenz	hybrid	hybrid	Präsenz

Praktischer Teil (Coding)

Als praktischen Teil nehmen wir den Microservice Dungeon. Hier sollen Sie in Teams von 2-3 Personen jeweils einen Player-Service entwickeln und sich dabei mit den Eigenschaften von Microservices auseinandersetzen. Die wesentlichen Links zu dem Projekt sind diese hier:

• Dokumentation des Microservice Dungeon
• Repos auf gitlab.com

Teams für praktischen Teil

Die Teams für die Fallstudie bilden sich selbst. Sie können sich in Teams von 2-3 Personen zusammenfinden. Im ILIAS-Kurs MSA finden Sie Gruppen “Player1” … “Player9”. Bitte tragen Sie sich dort in eine Gruppe ein. Ihre Bewertung für den Kurs erfolgt dann als Team.

Aufgaben im praktischen Teil

Achtung: In diesem Kurs sind wir ausschließlich im Backend unterwegs. Clients (UIs) sind nicht Bestandteil der Aufgabe. Sie können aber so etwas als Bonus machen (s.u.). Ihre Aufgabe im praktischen Teil wird sein:

1. Beschäftigen Sie sich mit Spiellogik und Architektur des Microservice Dungeon (siehe Dokumentation und zugehörige Repos). Legen Sie fest, welche Strategie Sie für Ihren Player, der Robots steuert, umsetzen wollen. Woran wollen Sie zuerst arbeiten
   • Robots kaufen
   • Robots über die Map bewegen
   • Ressourcen minen
   • Ressourcen verkaufen
   • Robots aufrüsten
   • andere Robots bekämpfen
   • verschiedene Typen von eigenen Robots unterstützen
   • …
2. Setzen Sie das lokale Dev Env auf (siehe “Getting Started” Guide), so dass es auf allen Rechnern Ihres Teams läuft.
3. Legen Sie ein Repo für Ihren Player auf gitlab.com an und geben uns Zugriff darauf. (Gitlab empfiehlt sich eher als Github, weil wir dort auch die anderen Repos haben und die Umsetzung des Deployments damit einheitlicher ist. Das macht es für Sie einfacher.)
4. Implementieren Sie einen Player. Jeder Player ist ein eigenständiger Service, der mit den Core-Services über REST und RabbitMQ-Events kommuniziert. Ein Player sollte einen Teil der oben genannten Funktionalitäten beherrschen (und zwar automatisiert, nicht durch manuelle Steuerung).
   • Bei der Technologie haben Sie freie Wahl - siehe unten “Technologiefreiheit”.
   • Ggfs. sollten Sie einen der Skeleton-Players forken und darauf aufbauen.
5. Bei der Implementation des Players werden wir im Kurs verschiedene Aspekte von Microservices und Event-driven Architecture anschauen, die in Ihrem Player als Herausforderungen auftreten.
6. Wenn Sie soweit kommen, können Sie in der zweiten Kurswoche Ihren Player in der Microservice-Dungeon-Umgebung deployen und dann mit anderen Playern einen Codefight machen.
7. Abschließend machen Sie am letzten Tag des Kurses eine Demo Ihres Players und reflektieren Ihre Arbeit (siehe Kriterien für die Abschlussreflektion).

Technologiefreiheit

Sie haben freie Wahl bei der Technologie Ihres Players! Nur die Protokolle für die Kommunikation mit den Core-Services sind gesetzt (REST bzw. AMQP, also das RabbitMQ-Messaging-Protokoll). Aber Sie haben damit auch die Verantwortung für Ihre Lösung. Es gibt keine Bonuspunkte für Exoten-Technologien, die Sie nicht beherrschen - also wählen Sie eine der nachfolgenden Optionen, die am ehesten zu Ihrem Team passt.

1. Es gibt vier Skeleton Players, die Sie als Basis für Ihren Player nehmen können. Dort ist der “anstrengende” Teil der Kommunikation mit den Core-Services schon implementiert:
   • Sie haben Code für den REST-Call zum Game-Service, um Kommandos abzusetzen
   • Die Anbindung an RabbitMQ ist schon implementiert, um Events zu empfangen (Antworten auf Ihre Kommandos und sonstige Nachrichten aus den Core-Services)
   • Die vier Typen von Skeleton Players sind in unterschiedlichen Technologien implementiert:
     • Java mit Spring Boot (mit umfassenden Unit Tests), Beratung durch Stefan Bente & Dennis Dubbert
     • Kotlin mit Koin (sehr gut dokumentiert), Beratung durch Dennis Dubbert
     • Typescript, Beratung durch Dennis Dubbert
     • Rust (noch in der Entwicklung, also nur für Teams, die wissen, was sie tun)
   • Wenn Sie einen der Skeleton Players verwenden wollen, dann sollten Sie das Repo forken und darauf aufbauen.
2. Sie können auch einen eigenen Player von Grund auf neu implementieren. Beachten Sie aber, dass Sie keine technische Unterstützung von mir oder anderen aus dem Microservice-Dungeon-Projekt erwarten können, wenn Sie auf eine Exoten-Technologie setzen - das müssen Sie dann selbst hinbekommen. Auch das Hosting ist Ihre Verantwortung.

Abschlussreflektion

Am letzten Freitag des Kurses machen wir eine Abschlussreflektion mit allen Teams. Dabei stellt jedes Team in einer praktischen Demo vor, wie weit sie mit dem Player gekommen sind. Außerdem beantwortet die Reflektion folgende Leitfragen:

1. Was hat mir in dem Architekturstil “Microservice” mit einer Event-Driven Architecture Schwierigkeiten bei Verständnis und Umsetzung gemacht? Was ist “anders” als bei früheren Software-Projekten von mir?
2. Was hat bei der Bewältigung der Komplexität geholfen?
3. Wenn ich an so ein Projekt (z.B. einer großen eCommerce-Plattform, die aus Microservices besteht) für Geld mitarbeiten würde - was würde ich individuell, als Team und/oder als Gesamtprojekt anders machen?
   • Bitte machen Sie realistische und konkrete Vorschläge
   • Also “Dafür sorgen, dass alle anderen Services keine Bugs haben” genügt nicht, Sie sollten auch schon vorschlagen, wie Sie das erreichen wollen.
4. Was nehme ich ganz persönlich aus dieser Fallstudie mit?

Sie brauchen keine Folien zu machen. Mündlich oder Hilfsmittel wie Miro-Board genügen. Jeder aus dem Team sollte an der Erstellung und Reflektion mitwirken. Die Leitfragen können Sie für das ganze Team beantworten (also sammeln).

Benotung

Die Benotung erfolgt in diesem Kurs in Teilgruppen, basieren auf einem Code Review des eigenen Players. Die Benotung orientiert sich an den obigen Anforderungen an den Player.

Notenbestandteil	Gewicht	0 Punkte	1 Punkt	2 Punkte	3 Punkte
Präsentation (Demo & Reflektionsfragen)	3	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.
Features, die der Player beherrscht	5	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	1	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.
Deployment und Codefight	3	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.
Weitergehende Leistungen	2	Keine über das geforderte Maß hinausgehenden Leistungen.	Überdurchschnittliches Engagement in einem Bereich (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.)	Deutlich mehr als gefordert in einem Bereich, oder überdurchschnittliches Engagement in mehreren Bereichen (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.)	Deutlich mehr als gefordert in mehreren Bereichen (besondere Features, ein UI-Client, umfassende Unit-Tests, außergewöhnlicher individueller Einsatz im eigenen Team oder der gesamten Gruppe, z.B. durch Helfen, etc.)

Damit sind inklusive weitergehender Leistungen insgesamt max. 42 Punkte erreichbar. Zum Bestehen (4,0) genügen 9 Punkte, eine 2,0 gibt es ab 27 Punkte, eine 1,0 ab 36 Punkte.

Anteil des individuellen Beitrags zur Teamleistung

Die Bewertung der obigen Punkte erfolgt im Team. Dabei gehe ich von einer gleichmäßigen Leistung aller Mitglieder aus. Wenn das nicht der Fall ist (wenn also z.B. ein Teammitglied sich erkennbar nicht oder deutlich weniger an der Gruppenarbeit beteiligt), dann behalte ich mir vor, bei diesem Teammitglied auch den Anteil an der Teamleistung geringer anzusetzen. Damit kann dann die individuelle Note auch von der Teamnote abweichen, und auch im Extremfall zu einem Nicht-Bestehen des Kurses führen.

Am besten stellen Sie sicher, dass Ihr individueller Beitrag erkennbar ist, Sie also z.B. bei Pair oder Mob Programming auch selbst Commits ins System pushen.

Literatur

Hier finden Sie bewusst eine längere Liste zum Weiterlesen. Die aus meiner Sicht wichtigsten Titel sind fettgedruckt.

1. Evans, E. (2015). Domain-Driven Design Reference—Definitions and Pattern Summaries. Domain Language, Inc. URL
2. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software (1st edition). Addison-Wesley Professional.
3. Fowler, M. (2017, February 7). What do you mean by “Event-Driven”? martinfowler.com. URL
4. Newman, S. (2021). Building Microservices: Designing Fine-Grained Systems (2nd ed.). O’Reilly and Associates.
5. Richardson, C. (2015, May 19). Introduction to Microservices. NGINX. URL
6. Steinacker, G. (2016, March 20). Why Microservices? Dev.Otto.De. URL
7. Vernon, V. (2013). Implementing Domain-Driven Design (01 ed.). Addison Wesley.
8. Wolff, E. (2015). Microservices: Grundlagen flexibler Softwarearchitekturen (1., Auflage). dpunkt.verlag.

Workshops

Mon 18.12.2023, 10:00 - 16:00: Kickoff

In diesem ersten Blocktag starten wir in die Veranstaltung, klären Organisatorisches, dann starten wir in das Thema mit einem Warmup und einem Planspiel.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Ziel des Tages

Sie wissen, was in den zwei Wochen auf Sie zukommt, haben die Domäne verstanden und Teams gebildet.

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: ZjR7=ve*).

Die nachfolgenden Videos bieten zusätzliche Informationen zum Thema

Agenda

• 10:00 - 10:45:  Organisatorisches
  • Zeitplan und Struktur der ersten und zweiten Woche (Workshops, Übungen, Videos)
  • Abstimmung zu den letzten beiden Tagen vor Weihnachten (Präsenz vs. Remote)
  • Youtube-Channel
  • Discord als präferiertes Kommunikationsforum
  • Einführung in die Aufgabenstellung im praktischen Teil
  • Benotung
• 10:45 - 12:00:  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?
  • Folien dazu liegen hier
• 12:00 - 13:00:  Mittagspause
• 13:00 - 14:30:  Planspiel "Die Siedler von Softan"
  • Synchrone vs. asynchrone Kommunikation, aber mal ganz analog ...
  • Hier stehen die Regeln für das Spiel.
• 14:30 - 16:00:  Einführung in das Microservice-Dungeon-Projekt
  • Spielidee
  • Architektur
  • Core-Services
  • Getting Started für die Player-Entwicklung
• 16:00 - 16:30:  Wrap-Up und Fragen
  • Abschließend Wrap-Up und Ende des Workshop-Tages

Aufgabe bis zum nächsten Workshop

• Bilden Sie Teams
• Besprechen Sie Ihre Technologiewahl
• Schauen Sie sich die Dokumentation des Microservice-Dungeon-Projekts an

Tue 19.12.2023, 10:00 - 16:00: DevEnv-Setup und Loslegen mit dem praktischen Teil

An diesem zweiten Blocktag wird es technischer. Wir setzen das DevEnv auf, und Sie starten mit der Arbeit an Ihrem Player. Ich gebe einen Impuls, wie man am besten startet.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Ziel des Tages

DevEnv steht, und Sie haben die ersten Schritte mit dem Player gemacht.

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: X6sCC#+g).

Agenda

• 10:00 - 10:15:  Fragen zum vorigen Tag und zum Microservice-Dungeon-Projekt
• 10:15 - 12:00:  DevEnv-Setup und Arbeitsplanung
  • Sie setzen das DevEnv lokal bei Ihnen auf (sollte bei jeder/m laufen!)
  • Wir helfen dabei, wenn es Probleme gibt
• 12:00 - 13:00:  Mittagspause
• 13:00 - 14:00:  Besonderheit bei Microservices - Asnchrone Kommunikation
  • Synchrone Kommunikation (Request/Response) ist einfach, aber nicht immer die beste Wahl - besonders bei großen verteilten und lose gekoppelten Systemen wie Microservices.
  • Dadurch entstehen viele mögliche Stolpersteine und potentielle Performance-Engpässe.
  • Daher ist das präferierte Kommunikationsmuster bei Microservices asynchron, also Event-getrieben. Das ist für viele Entwickler\*innen ungewohnt, und es gibt viele Fallstricke.
  • Die Unterschiede zwischen synchrone und asynchrone Kommunikation sind in diesen Folien kurz vorgestellt.
• 14:00 - 16:00:  Arbeit am Player und Planung für den Rest der Woche
  • Sie coden an Ihrem Player in Ihren Teams

Aufgabe bis zum nächsten Workshop

• Versuchen Sie die Materie soweit zu verstehen, dass Sie mit der Arbeit am Player für den Rest der Woche weitermachen können
• Sammeln Sie Fragen

Wed 20.12.2023: Selbstlerntag

Aufgabe bis zum nächsten Workshop

• Wer möchte, kann Aufgabenstellungen individuell besprechen

Thu 21.12.2023, 10:00 - 16:00: MSA-Workshop

Die Workshops folgen einem ähnlichen Muster. Wir starten mit Fragen zum vorigen Tag, dann gibt es einen Impuls zu einem Thema, dann arbeiten Sie selbstständig an Ihrem Player.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: jkjkj_88kah).

Agenda

• 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
• 10:15 - 10:45:  Dev Mode im Java Skeleton
  • Der Dev Mode im Java Skeleton ermöglicht ein einfaches Entwickeln im lokalen Dev Env, weil das Game automatisch gestartet wird.
  • Wir schauen uns an, wie der Dev Mode aktiviert wird und wie er wirkt.
  • Die Sequenz der Commands, Queries und Events, die beim Starten des Dev Mode ablaufen, findet man hier dokumentiert.
• 10:45 - 11:30:  Was ist eigentlich der Unterschied zwischen "normalen" Programmen und einer Event-getriebenen Architektur wie bei einem Microservice?
  • Wir schauen uns die grundsätzlichen Ablaufmuster einmal schematisch an.
  • Dann schauen wir auf den Code des Java Player Skeletons, um die einzelnen Bestandteile besser zuordnen zu können.
  • Habe ich anhand eines Scribbles erklärt - am besten schaut man sich das zusammen mit der Video-Aufzeichnung an.
• 11:15 - 15:45:  Coding-Session mit individueller Arbeitszeit und Beratung durch die Betreuer
  • dazwischen Mittagspause
• 15:45 - 16:00:  Wrap-Up und Fragen
  • Abschluss des Tags

Fri 22.12.2023, 10:00 - 11:45: MSA-Workshop

Die Workshops folgen einem ähnlichen Muster. Wir starten mit Fragen zum vorigen Tag, dann gibt es einen Impuls zu einem Thema, dann arbeiten Sie selbstständig an Ihrem Player.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: 3CQC1&4s).

Agenda

• 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
• 10:15 - 11:45:  Live Coding - How to Start My Player
  • Ich gehe einmal mit Ihnen die Schritte durch, die man für den eigenen Player braucht.
  • Ziel ist ein Minimal-Player (ich kaufe 5 Robots und lasse die "random" über die Map laufen, ohne etwas zu machen).
  • Siehe oben der Link zur Videoaufzeichnung
• 11:45 - 11:46:  Merry Xmas and Happy New Year!

Mon 08.01.2024, 10:00 - 16:00: Recap aus der Zeit zwischen den beiden Kurswochen, und Coding

Probleme beim Coding, Updates aus dem Skeleton Player, und der weitere Verlauf der Veranstaltung. Dazu arbeiten Sie mit Betreuung weiter an Ihrer Lösung.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28). Es gibt zusätzlich eine Videokonferenz. Videokonferenz-Link: https://th-koeln.zoom-x.de/j/61363685608?pwd=VnZFWjh3dnMzRHVyUU4xeVFlcUFpdz09

Ziel des Tages

Eventuelle Probleme sind gefixt, und Sie sind auf dem Weg zum lauffähigen Player.

Agenda

• 10:00 - 12:00:  Fragen aufgetretenen Problemen beim Coding
  • Stefan Bente ist vor Ort in der 423, Döner ist online dabei
• 12:00 - 13:00:  Mittagspause
• 13:00 - 13:30:  Orga, Updates aus dem Skeleton Player, Beta-Dashboard
  • Orga und weiterer Zeitplan
  • Local Dev Environment Update - jetzt gibt es ein Dashboard (Beta) lokal
  • Wir schauen uns die Fixes im Skeleton Player an (Autostart im Dev Mode, Lombok-Problem, CI-Konfiguration)
  • Merge der Changes aus dem Skeleton Player
• 13:30 - 15:45:  Coding-Session mit individueller Arbeitszeit und Beratung durch die Betreuer
• 15:45 - 16:00:  Wrap-Up und Fragen
  • Abschluss des Tags

Tue 09.01.2024, 10:00 - 16:00: Deployment des eigenen Players

In diesem Workshop geht es um das Deployment des eigenen Players in die Produktivumgebung. Das ist Voraussetzung, damit Ihr Player am Codefight teilnehmen kann. Es gibt dabei einige Fallstricke. Darüber hinaus arbeiten Sie weiter an Ihrem Player.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28). Es gibt zusätzlich eine Videokonferenz. Videokonferenz-Link: https://th-koeln.zoom-x.de/j/61363685608?pwd=VnZFWjh3dnMzRHVyUU4xeVFlcUFpdz09

Ziel des Tages

Es ist klar geworden, wofür man das Deployment in eine Produktivumgebung braucht, und Sie haben Ihren Player erfolgreich in die Prod-Umgebung des Microservice Dungeon deployed.

Agenda

• 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
• 10:15 - 12:00:  Deployment - wieso braucht man das, wie macht man das?
• 12:00 - 13:00:  Mittagspause
• 13:00 - 15:45:  Deployment und Coding-Session mit individueller Arbeitszeit und Beratung durch die Betreuer
  • Wir helfen insbesondere bei Problemen mit dem Deployment
• 15:45 - 16:00:  Wrap-Up und Fragen
  • Abschluss des Tags

Wed 10.01.2024: Selbstlerntag

Aufgabe bis zum nächsten Workshop

• Wer möchte, kann Aufgabenstellungen individuell besprechen

Thu 11.01.2024, 10:00 - 16:00: Codefight und Vorbereitung der End-Präsentation am Freitag

Bereiten Sie Ihren Player für eine Präsentation vor. Arbeiten Sie weiter am Code, und überlegen Sie sich die Punkte für die Teampräsentation mit Reflektion am Freitag. Dann gibt es die Teampräsentationen und eine Abschluss-Retro.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Ziel des Tages

Ihr Player hat "irgendwie" am Codefight teilgenommen.

Agenda

• 10:00 - 11:30:  Vorbereitung Codefight
  • Deployment funktioniert bei allen, die teilnehmen wollen?
• 11:30 - 12:30:  Codefight
  • Spiel wird zentral gestartet
  • Mal schauen, ob das Beta-Dashboard bis dahin auch in Prod läuft - ansonsten gucken wir das auf dem Client von Player MONTE (oder was sonst noch geht).
  • Erwartungen sollten nicht zu hoch hängen - mal sehen, ob wirklich jemand kämpft, aber es wäre schön, wenn wir das ein paar Players mit sich bewegenden und minenden Robots sehen.
• 12:30 - 13:30:  Mittagspause
• 13:30 - 15:45:  Vorbereitung der End-Präsentation am Freitag
  • Vorbereitung der Leitfragen für die Abschlussreflektion in den Subteams
  • Folien sind nicht nötig, Notizen und mündlicher Vortrag reichen
  • Vorbereitung einer Demo des Players
• 15:45 - 16:00:  Wrap-Up und Fragen
  • Abschluss des Tags

Fri 12.01.2024, 10:00 - 15:00: Abschlusspräsentation und Retro

Sie präsentieren Ihre Player und reflektieren Ihre Erfahrungen anhand der Leitfragen.

Ort des Workshops

Raum: 423 (Code & Context, Standort Köln Mülheim, Schanzenstr. 28).

Agenda

• 10:00 - 10:30:  Letzte Vorbereitungen
• 10:30 - 12:30:  Abschlusspräsentation
  • Immer Subteam-weise
  • Bitte nicht mehr als 20 min pro Team
  • Reihenfolge wird durch random.org ermittelt ...
  • Reflektion gemäß der Leitfragen
  • Demo des Players mit Übersicht, was er kann (und was nicht)
• 12:30 - 13:30:  Mittagspause
• 13:30 - 15:00:  Abschluss-Retro
  • Wir schauen auf die gesamte Veranstaltung zurück.