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.

Microservice Architectures (MSA), WS24

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
14.10.2024 - 25.10.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: Open Space (Code & Context, Standort Köln Mülheim, Schanzenstr. 28)
Videokonferenz-Link: https://th-koeln.zoom-x.de/j/62579352103?pwd=SVBoXFyqpVhSouraSObJuYXpDmPIpV.1 (nur in Ausnahmefällen und wenn explizit vorher für den Tag kommuniziert)
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.)

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 14.10. Di 15.10. Do 17.10. Fr 18.10. Mo 21.10. Di 22.10. Do 24.10. Fr 25.10.
Präsenz Präsenz Präsenz Präsenz Präsenz hybrid Präsenz 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:

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. Legen Sie einen Player-Namen fest und teilen mir mit:

Zusammenarbeit ist gewollt, simples Copy-Paste ist ein Täuschungsversuch

Jedes Team muss eine eigenständige Bearbeitung der Praktikumsaufgabe durchführen. Diskutieren Sie Ihre Lösungen gern untereinander (zwischen den Teams). Ein einfaches Copy-Paste von Lösungen wird aber als Täuschungsversuch gewertet. (Man kann die abgegebenen Lösungen mit Tools auf Code-Ähnlichkeit prüfen.)

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 in https://gitlab.com/msd-players/msa-ws24 an.
  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 (sehr gut dokumentiert, mit umfassenden Unit Tests),
      • Kotlin mit Koin (sehr gut dokumentiert),
      • Typescript
      • Rust
    • 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). Länge sollte so etwa 5-10 min pro Teilnehmer:in sein, aber bitte nicht mehr als 20 min für das gesamte Team.

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) 2 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 2 Die Architektur des Players zeigt kein wirkliches Verständnis verteilter, asynchron kommunizierender Anwendungen. 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 Architektur des Players zeigt nur elementares Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist teilweise inkonsistent. 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 Architektur des Players zeigt ein zufriedenstellendes Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist weitgehend konsistent. 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 Architektur des Players zeigt ein volles Verständnis verteilter, asynchron kommunizierender Anwendungen, und ist durchgehend konsistent. 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 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.
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. 36 Punkte erreichbar. Zum Bestehen (4,0) genügen 11 Punkte, eine 1,0 gibt es ab 32 Punkte. Bei ‘Bewertung der Softwarequalität’ muss genügend Code-Menge für eine Bewertung mit mehr als 1 Punkt vorhanden sein.

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 14.10.2024, 10:00 - 16:00: Kickoff

In diesem ersten Blocktag starten wir in die Veranstaltung, klären Organisatorisches, dann starten wir in das Thema.

Ort des Workshops

Raum: Open Space (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, Teams gebildet, und das DevEnv aufgesetzt.

Videoaufzeichnung

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)
    • Youtube-Channel
    • Discord als präferiertes Kommunikationsforum
    • Einführung in die Aufgabenstellung im praktischen Teil
    • Benotung
    • (Anmerkung - bei der Videoaufzeichnung habe ich leider vergessen, den Bildschirm zu sharen, ist also nur Ton. Sorry dafür.)
  • 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?
    • Hier sind die Folien
  • 12:00 - 13:00:  Mittagspause
  • 13:00 - 14:30:  Einführung in das Microservice-Dungeon-Projekt
  • 14:30 - 16:00:  DevEnv-Setup und Arbeitsplanung
    • Sie setzen das DevEnv lokal bei Ihnen auf (sollte bei jeder/m laufen!)
    • Ich helfe dabei, wenn es Probleme gibt

Aufgabe bis zum nächsten Workshop

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

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

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

Ort des Workshops

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

Ziel des Tages

Sie haben die ersten Schritte mit dem Player gemacht.

Videoaufzeichnung

Agenda

  • 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
  • 10:15 - 12:00:  Live Coding - erste Schritte in meinem 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).
    • Die wesentlichen Abläufe sieht man auch in diesem Scribble (bitte zusammen mit der Videoaufzeichnung anschauen, sonst versteht man es wahrscheinlich nicht)
    • Sie versuchen die Schritte mal selbst nachzuvollziehen
  • 12:00 - 13:00:  Mittagspause
  • 13:00 - 16:00:  Loslegen mit dem Player
    • Sie wählen den Startpunkt für die Entwicklung aus (Technologie, ggfs. einen der Skeletons)
    • Sie planen die ersten Entwicklungsschritte
    • DevEnv läuft lokal bei Ihnen
    • 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 16.10.2024: Selbstlerntag

Aufgabe bis zum nächsten Workshop

  • Wer möchte, kann Aufgabenstellungen individuell besprechen

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

Heute schauen wir auf die grundsätzlichen Unterschiede zwischen synchroner und asynchroner Kommunikation, dann arbeiten Sie selbstständig weiter an Ihrem Player.

Ort des Workshops

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

Videoaufzeichnung

Agenda

  • 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
  • 10:15 - 11:30:  Weiterführen des Life-Codings am Beispiel des "Freddie Krueger" Players
    • Wir gehen zusammen den Freddie Krueger Player durch, um die ersten Schritte zu verstehen.
    • Sie können sich den Code clonen und bei sich im Player verwenden, um loslaufen zu können.
  • 11:30 - 12:00:  ... und was heißt das konkret für meinen Player?
    • 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.
    • Siehe auch das oben erwähnte Scribble.
  • 12:00 - 13:00:  Mittagspause
  • 13:00 - 16:00:  Coding-Session mit individueller Arbeitszeit und Beratung durch den Betreuer
    • mit Gelegenheit zu Fragen und Hilfestellungen

Fri 18.10.2024, 10:00 - 12:00: MSA-Workshop

Wir schauen uns gemeinsam an, wie Entwickeln im Team funktioniert. Dann arbeiten Sie selbstständig an Ihrem Player.

Ort des Workshops

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

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: yvryV^@2).

Agenda

  • 10:00 - 10:15:  Fragen zum vorigen Tag und zum Microservice-Dungeon-Projekt
  • 10:15 - 10:45:  Entwickeln im Team
    • In einem kurzen Impuls stelle ich Ihnen eine Strategie vor, wie Sie mit Hilfe von Git im Team entwickeln können.
    • Hier sind die Folien dazu.
  • 10:45 - 12:00:  Coding-Session mit individueller Arbeitszeit und Beratung durch Betreuer

Mon 21.10.2024, 10:00 - 16:00: DevOps und Entwicklung

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

Ziel des Tages

Es ist klar geworden, wofür man das Deployment in eine Produktivumgebung braucht, und Sie haben für Ihren Player ein Docker-File in der Gitlab-Container-Registry.

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: 4Fv+TpTx).

Agenda

  • 10:00 - 10:15:  Fragen aufgetretenen Problemen beim Coding
  • 10:15 - 11:15:  DevOps - wieso braucht man das, wie macht man das?
    • Was ist DevOps? Wozu ist das gut? Warum zahlt das auf eine Microservice-Architektur ein?
    • Was muss im Dungeon-Deployment konkret gemacht werden?
    • Wir spielen die Schritte einmal anhand eines konkreten Players durch.
    • Hier sind die Folien dazu.
  • 11:15 - 16:00:  Coding-Session mit individueller Arbeitszeit und Beratung durch Betreuer
    • Dazwischen Mittagspause

Tue 22.10.2024, 10:00 - 16:00: Synchrone vs. asynchrone Kommunikation - was braucht man wann?

Stefan Bente ist an dem Tag nur remote verfügbar. Der Open Space ist aber offen. Neben einem Impuls zu synchroner vs. asynchroner Kommunikation arbeiten Sie weiter an Ihrem Player.

Ort des Workshops

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

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: iX4!?*9!).

Agenda

  • 10:00 - 10:15:  Fragen zum vorigen Tag und zum Code
  • 10:15 - 11: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 den Folien kurz vorgestellt.
  • 11:15 - 16:00:  Coding-Session mit individueller Arbeitszeit und Beratung durch Betreuer
    • Dazwischen Mittagspause

Wed 23.10.2024: Selbstlerntag

Aufgabe bis zum nächsten Workshop

  • Wer möchte, kann Aufgabenstellungen individuell besprechen

Thu 24.10.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. Dazwischen machen wir 2x einen Codefight.

Ort des Workshops

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

Ziel des Tages

Ihr Player hat "irgendwie" am Codefight teilgenommen.

Videoaufzeichnung

Eine Videoaufzeichnung gibt es hier. (Passwort: iBG!typ2).

Agenda

  • 10:00 - 10:30:  Rundlauf zum aktuellen Stand
  • 10:30 - 10:45:  Vorbereitung und Besprechung der Abschlussreflektion am Freitag
  • 10:45 - 11:30:  Erster Codefight
    • Wir machen den Codefight zur Vereinfachung nicht auf dem Cluster, sondern auf einem speziellen lokalen dev env auf meinem (ziemlich starken) Laptop.
    • Alle mit validem Docker-Image können teilnehmen.
  • 11:30 - 14:30:  Coding-Session und Vorbereitung Abschlussreflektion
    • Dazwischen Mittagspause
  • 14:30 - 15:00:  Zweiter Codefight
    • Nochmal ein neuer Versuch.
  • 15:00 - 16:00:  Individueller Arbeitszeit

Fri 25.10.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: Open Space (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.