docs: add obsidian hwr docs

Studienarbeit II/Inhalte.md

@@ -0,0 +1,28 @@
+---
+share_link: https://share.note.sx/kce43il1#4EXkK8s6Yf+GsV46leOCXZUiTeIrCIxRNvupy6vOwU8
+share_updated: 2025-12-09T13:51:04+01:00
+---
+
+# Inhaltswünsche von Zimmi
+
+- Funktionale und Nichtfunktionale Anforderungen
+- Literaturarbeit
+- Grafiken/Struktogramme zu Aufbau und Kommunikation der Modelle, Aufbau des Architektur Stacks, TCP Protokoll Struktur (**Entwurfskapitel**)
+- Screenshots der Anwendung in Light Mode (**Algorithmenkapitel** oder **Anhang**)
+
+# Inhaltsverzeichnis
+
+1. **Abstract** 
+2. **Einleitung**
+3. **Problemstellung**
+4. **Anforderungsanalyse**
+	1. Funktionale
+	2. Nichtfunktionale
+5. **Theoretische Grundlagen** (Erklärung aller notwendigen Prinzipien für die Entwicklung der Erweiterung, z.B. tiefere theoretische  Erklärung des Findens von anderen Instanzen im lokalen Netzwerk)
+6. **Entwurf** (Referenzen zu Anforderungen)
+	1. Strukturelle Veränderungen im Backend
+	2. Strukturelle Veränderungen im Frontend
+7. **Algorithmen** (Referenzen zu Anforderungen)
+	1. Pro konkreter Codeänderung ein Unterabschnitt
+8. **Diskussion** (Vergleich Vorher/Nachher nach der Erweiterung der Software in Aspekten wie der Nutzerfreundlichkeit und der Nutzbarkeit der Software)
+9. **Fazit**

Studienarbeit II/Vortragsnotizen.md

@@ -0,0 +1,46 @@
+# Vortragsnotizen:
+
+## 1. Status Quo (auch Randbedingungen)
+### Technologien
+- Golang als Programmiersprache (unverändert)
+- Goland als IDE (in Studienprojekt I)
+- VSCode (Editor mit Extension wegen besserer WSL Kompatibität)
+- Fyne als Frontend-Go-Library (unverändert)
+- Überlegung: Frontend-Framework als Frontend mit REST-API Kommunikation (React, Angular, Vue)
+	- mehr Aufwand der nur die Inconvinience von Fyne lösen würde
+	- Probleme mit Wails für Web-Framework-Desktop Apps
+	- somit mehr Aufwand als funktionale Veränderungen
+	- deshalb bei Fyne bleiben mit Kommunikation über Signal Channel
+
+- TCP/IP als Protokoll weiterhin
+- Testing: Zwei Szenarien:
+	- Zwei Computer (inconvinient)
+	- Zwei Instanzen auf dem selben Computer oder zwei VMs haben sich eher bewährt wegen Zeiteffizienz
+
+### Funktionalitäten
+- Bisher bauen wir auf einer Software auf mit:
+	- Netzwerk: Lokale automatische TCP-Verbindungen 
+	- TCP-Paketversand automatisch in drei verschiedenen Verzögerungen
+	- Pakete werden visualisiert über Balkendiagramme 
+	- Verbindungsstatus LED für den User
+	- Dark Mode für Barriefreiheit, wie reduzierte Augenbelastung und bessere Lesbarkeit
+	- Fenster kann im Vollbild genutzt werden mit automatischer Skalierung der UI-Elemente
+	- Cross-Platform kompatibel, Auslieferung für Windows, Linux und MacOS
+
+## Frontend-Erweiterungen
+### Peer-Discovery
+- Vorher: Nutzer kann nicht sehen mit welchem anderen Peer er verbunden ist, nur dass er überhaupt verbunden ist oder nicht
+- Snapdrop UI nicht realisiert weil:
+	- Fyne arbeitet mit statischen Layouts und nativen Widgets 
+	- Radar-Zeichnung im Canvas zu komplex zur Erhaltung der Wartbarkeit des Code
+	- Stattdessen Stärke von Fyne: Grid-Layout
+	- Für Snapdrop Frontend-Austausch durch Web-Framework nötig leider (besser lösbar darin)
+
+- **Button Grid** für verfügbare Instanzen, blau/weiß oder blau/schwarz für hohen kontrast
+- Grid wird vom Backend alle 100ms aktualisiert
+- **Responsiveness im Button Grid Container** : 
+	- Schmales Fenster: Nur zwei Buttons nebeneinander
+	- Breites Fenster: Vier Buttons nebeneinander,
+- Vorher: User klickt auf Button -> verbindet sich -> kann nur disconnecten indem er das Programm schließt
+- Disconnect Button im verbunden Zustand
+- Keine Peers werden angezeigt, weil die aktuelle Instanz schon verbunden ist

Studienarbeit II/Workspace fürs Schreiben.md

@@ -0,0 +1,13 @@
+# Workspace Struktur
+
+studienarbeit/
+├── network-interaction/
+├── network-interaction-deepwiki/
+├── studienarbeit-i/
+└── studienarbeit-ii/
+
+**Github-Repo Network-Interaction**: https://github.com/theoleuthardt/network-interaction
+**Github-Repo Studienarbeit II**: https://github.com/theoleuthardt/studienarbeit-ii
+**Deepwiki**: https://deepwiki.com/theoleuthardt/network-interaction/
+**DeepwikiToMarkdown**: https://github.com/zxmfke/deepwiki-md-chrome-extension
+

Studienarbeit II/evaluation_studienarbeit_i.md

@@ -0,0 +1,101 @@
+# Evaluation
+Diese Evaluation der Studienarbeit I ist in numerierte Teilbewertungskriterien unterteilt.
+Jedes Kriterium hat Inhalte, die bewertet werden, einen Bewertungstext und eine Punktzahl.
+
+## 1. Theoretische Betrachtungen
+### Inhalte des Bewertungskriteriums
+- Literaturarbeit
+- Kritische Diskussion voriger Arbeiten
+- Nachvollzierbarkeit der Aussagen
+- Entscheidungskriterien
+- Argumentationsweise 
+
+### Bewertung
+Literaturarbeit ist vorhanden. Die vorigen Arbeiten werden ausführlich besprochen (Punkt 3.1). Argumentationsweise ist 
+logisch, die Entscheidungskriterien sind nachvollziehbar.
+
+### Punktzahl
+20 von 20
+
+## 2. Praktische Ausführung
+### Inhalte des Bewertungskriteriums
+- Analyse, Entwurf, Konzept
+- Dis kussion von Realisierungsansätzen
+- Evaluierung, Testen
+- Praktische Anwendung fachlichen Wissens
+- Auswahl und Einsatz von Hilfsmitteln 
+
+### Bewertung
+Die Anforderungsanalyse scheint spärlich zu sein: Im Punkt 2.3. sind neben den Anforderungen vielmehr die algorithmische 
+Vorgehensweise besprochen. Im Punkt 6 tauchen plötzlich "die Limits und Skalierbarkeit der Software" auf, die nicht unter 
+Anforderungen aufgelistet sind. Es wäre ratsam, die Anforderungen in funktionale und nicht-funktionale zu unterteilen und 
+strukturiert (z.B. als Tabelle) darzustellen [-2]. Die Anforderung bezüglich Sprache Go findet man dort auch nicht explizit, 
+obwohl in anderen Teile ist sie präsent. Die Programme sind strukturiert geschrieben. Fazit und Ausblick sind vorhanden. 
+Die im Studium erworbenen Kenntnisse sind fachlich umgesetzt.
+
+### Punktzahl
+23 von 25
+
+## 3. Eigeninitiative, Einsatz und Arbeitsstil
+### Inhalte des Bewertungskriteriums
+- Eigene Ideen, Selbstständigkeit
+- Krit ikfähigkeit
+- Arbeitsstil
+- Arbeitsorganisation 
+
+### Bewertung
+Die Erarbeitung erfolgte selbstständig. Organisierte und strukturierte Arbeitsweise ist gut erkennbar.
+
+### Punktzahl
+5 von 5
+
+## 4. Inhalt der Dokumentation
+### Inhalte des Bewertungskriteriums
+- Fachlicher Gehalt
+- Darstellung der Zielrichtung
+- Definition der Randbedingungen
+- Herausarbeiten der Schwerpunkte
+- Diskussion der Ergebnisse 
+
+### Bewertung
+Ziele sind im Punkt 2 zu erkennen. Forschungsansatz und Vorgehensweise sind wohl durchdacht. Die Randbedingungen sind 
+leider nicht vorhanden, aber lassen sich teilweise im Text erkennen. Die Schwerpunkte sind passend erarbeitet und vorgestellt. 
+Es fehlen aber die im Punkt 2.3 versprochenen grafischen Darstellungen der funktionierenden Anwendung [-2]. Ergebnisse 
+sind kritisch evaluiert und diskutiert.
+
+### Punktzahl
+18 von 20
+
+## 5. Form der Dokumentation
+### Inhalte des Bewertungskriteriums
+- Gliederung, Übersichtlichkeit
+- Stil, Grammatik
+- Verweise, Zitierungen
+- Literaturverzeichnis, Literaturquellen 
+
+### Bewertung
+Die Gliederung ist gut strukturiert und bildet den Inhalt der Arbeit ab. Die Auslegung wird passend mit Bildern, 
+Source-Code und Tabellen begleitet. Stil und Grammatik sind für eine wissenschaftliche Arbeit geeignet. Literaturverzeichnis 
+enthält gute Referenzen. Umfang der schriftlichen Arbeit ist kurz (22 Seiten) [-2]. 
+
+### Punktzahl
+8 von 10
+
+## 6. Referat
+### Inhalte des Bewertungskriteriums
+- Einführung ins Thema, Sachgehalt
+- Aufbau, Bezüge, roter Faden
+- Timing, Umgang mit Medien
+- Vorbereitung, Kompetenz, Vortragsstil
+- Folien (Lesbarkeit/Aufteilung/Quellen) 
+
+### Bewertung
+Das Referat stellt das Thema umfassend dar. Der rote Faden ist nachvollziehbar. Aus der Präsentation wird klar, dass 
+die grundlegenden Ziele, Anforderungen und die Methodik, es umzusetzen, vorstellbar für den Autor sind. Timing ist optimal,
+Vortragsstil ist kompetent. Die Folien sind gut lesbar, die Literaturquellen sind vorhanden.
+
+### Punktzahl
+20 von 20
+
+## Gesamtpunktzahl
+94 von 100

Studienarbeit II/presentation_notes.md

@@ -0,0 +1,46 @@
+# Vortragsnotizen:
+
+## 1. Status Quo (auch Randbedingungen)
+### Technologien
+- Golang als Programmiersprache (unverändert)
+- Goland als IDE (in Studienprojekt I)
+- VSCode (Editor mit Extension wegen besserer WSL Kompatibität)
+- Fyne als Frontend-Go-Library (unverändert)
+- Überlegung: Frontend-Framework als Frontend mit REST-API Kommunikation (React, Angular, Vue)
+	- mehr Aufwand der nur die Inconvinience von Fyne lösen würde
+	- Probleme mit Wails für Web-Framework-Desktop Apps
+	- somit mehr Aufwand als funktionale Veränderungen
+	- deshalb bei Fyne bleiben mit Kommunikation über Signal Channel
+
+- TCP/IP als Protokoll weiterhin
+- Testing: Zwei Szenarien:
+	- Zwei Computer (inconvinient)
+	- Zwei Instanzen auf dem selben Computer oder zwei VMs haben sich eher bewährt wegen Zeiteffizienz
+
+### Funktionalitäten
+- Bisher bauen wir auf einer Software auf mit:
+	- Netzwerk: Lokale automatische TCP-Verbindungen 
+	- TCP-Paketversand automatisch in drei verschiedenen Verzögerungen
+	- Pakete werden visualisiert über Balkendiagramme 
+	- Verbindungsstatus LED für den User
+	- Dark Mode für Barriefreiheit, wie reduzierte Augenbelastung und bessere Lesbarkeit
+	- Fenster kann im Vollbild genutzt werden mit automatischer Skalierung der UI-Elemente
+	- Cross-Platform kompatibel, Auslieferung für Windows, Linux und MacOS
+
+## Frontend-Erweiterungen
+### Peer-Discovery
+- Vorher: Nutzer kann nicht sehen mit welchem anderen Peer er verbunden ist, nur dass er überhaupt verbunden ist oder nicht
+- Snapdrop UI nicht realisiert weil:
+	- Fyne arbeitet mit statischen Layouts und nativen Widgets 
+	- Radar-Zeichnung im Canvas zu komplex zur Erhaltung der Wartbarkeit des Code
+	- Stattdessen Stärke von Fyne: Grid-Layout
+	- Für Snapdrop Frontend-Austausch durch Web-Framework nötig leider (besser lösbar darin)
+
+- **Button Grid** für verfügbare Instanzen, blau/weiß oder blau/schwarz für hohen kontrast
+- Grid wird vom Backend alle 100ms aktualisiert
+- **Responsiveness im Button Grid Container** : 
+	- Schmales Fenster: Nur zwei Buttons nebeneinander
+	- Breites Fenster: Vier Buttons nebeneinander,
+- Vorher: User klickt auf Button -> verbindet sich -> kann nur disconnecten indem er das Programm schließt
+- Disconnect Button im verbunden Zustand
+- Keine Peers werden angezeigt, weil die aktuelle Instanz schon verbunden ist