... | @@ -297,5 +297,81 @@ Kopplungen werden bei neuem Smart Contract wieder aufgelöst. Wie ist es möglic |
... | @@ -297,5 +297,81 @@ Kopplungen werden bei neuem Smart Contract wieder aufgelöst. Wie ist es möglic |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 22.06.2023
|
|
|
|
|
|
|
|
# 22.06.2023
|
|
|
|
|
|
|
|
Juri ist diese Woche Krank :disappointed:
|
|
|
|
|
|
|
|
**Showcase:**
|
|
|
|
|
|
|
|
Send to Friend:
|
|
|
|
- Oskar demonstriert, dass die Tickets, die nur von uns stammen, nur in der Wallet sind. Alles funktioniert reibungslos.
|
|
|
|
- Oskar zeigt die "Send to Friend"-Funktion. Er meldet sich als neuer Benutzer an, der kein Ticket hat. Dann wechselt er zum Admin-Bereich und sendet das Ticket an den neuen Benutzer.
|
|
|
|
- Es wird erwähnt, dass wir keine gute Lösung gefunden haben, um den Ladebalken zu setzen. Marcus schlägt vor, dem Benutzer einfach eine Nachricht anzuzeigen, was ausreichend sein sollte.
|
|
|
|
|
|
|
|
Rollenmanagement:
|
|
|
|
- Orlando zeigt das Rollenmanagement für die Unterschiedliche Gruppen von Users auf unsere platform.
|
|
|
|
- Der Admin hat das Benutzermanagement. Er kann alle Benutzer einsehen, bearbeiten und löschen.
|
|
|
|
- Orlando erwähnt die Probleme mit "isAdmin" und "isEventmanager", die immer noch ein Problem im Frontend darstellen.
|
|
|
|
- Orlando zeigt am Ende des Meetings nochmal, dass die Rollen richtig funktionieren, bemerkt jedoch ein Problem mit der Asynchronität.
|
|
|
|
|
|
|
|
Deployment:
|
|
|
|
- Die Datenbank befindet sich in der Atlas-Cloud und alles funktioniert wie geplant.
|
|
|
|
- Deployment: Vercel
|
|
|
|
- Problem:
|
|
|
|
1. Wir benötigen einen DNS-Eintrag. -> Die Verwendung einer eigenen Domain ist ein kostenpflichtiges Feature.
|
|
|
|
2. Fehler dokumentieren und lösen, da wir eine intelligente Lösung haben.
|
|
|
|
3. Bilder sollten eine eigne Kollektion haben.
|
|
|
|
|
|
|
|
|
|
|
|
Test:
|
|
|
|
- Felix zeigt die Tests.
|
|
|
|
- Er zeigt die Code Coverage, was bei knapp 50-60% liegen.
|
|
|
|
- Problem:
|
|
|
|
1. Die CI-Pipeline von GitLab von BHT hat zu wenige Rechte und viele Einschränkungen. Daher versuchen wir möglicherweise Docker oder die Verwendung von GitHub, da das Deployment dort ebenfalls erfolgt.
|
|
|
|
2. Felix fragt nach den Rohdaten der Tests. -> Jenkins ist eine Software für CI/CD-Tools die das Problem von der Darstellung für die Wiki lösen könnte.
|
|
|
|
3. Wir prüfen, ob wir möglicherweise auch das Reporting mit Vercel integrieren können.
|
|
|
|
- Für das Wiki reicht es aus, den Prozess gut zu beschreiben und einen Screenshot der Code Coverage hinzuzufügen. Für den Rest kann es als zukünftige Funktionen erwähnt werden, dass wir das Reporting integrieren möchten.
|
|
|
|
|
|
|
|
Marcus ist zufrieden! :smile:
|
|
|
|
- Wir müssen einfach alles gut dokumentieren und Probleme beschreiben.
|
|
|
|
|
|
|
|
|
|
|
|
**Präsentation:**
|
|
|
|
Generelle Vorgaben (sollten aber auch eigene Inputs von uns einbeziehen):
|
|
|
|
- Problemstellung: Klare Formulierung und Beschreibung.
|
|
|
|
- Motivation.
|
|
|
|
- Überblick über die wichtigsten Merkmale und Funktionen.
|
|
|
|
- Technische Details: Erläuterungen zu Technologien, Entwurfsmustern, Algorithmen.
|
|
|
|
- Visualisierung der Architektur: Frontend, Backend, Datenbank, dezentrale Blockchain.
|
|
|
|
- Verwendung von Bildern anstelle von Stichpunkten, um das Gesagte zu unterstützen.
|
|
|
|
- User Journeys (Prozesse).
|
|
|
|
- UML-Diagramme.
|
|
|
|
- Testing und Bewertung:
|
|
|
|
1. Playtests, Analyse und Bewertung,
|
|
|
|
2. automatisierte Tests, Unit Tests (Screenshots)
|
|
|
|
3. User-Feedback aus Playtests.
|
|
|
|
- Distribution & Deployment: Strategie, Kosten für Domain eventuell erwähnen und solche Sachen ie eventuell wichtige wären
|
|
|
|
- Live demo (SEHR WICHITG!!!):
|
|
|
|
1. Üben, sodass alles passt in der Präsi.
|
|
|
|
2. Es ist wichtig, dass alle Teammitglieder die Präsentation durchführen können, falls die dafür vorgesehene Person nicht verfügbar ist.
|
|
|
|
3. Viel Testen, sodass bei der Präsi, alles nach Plan geht.
|
|
|
|
4. Rollen spiel könnte für unsere Darstellung interessant sein.
|
|
|
|
5. Verwendung von aussagekräftigen Mock-Daten für Benutzer (statt "test@test.com") zur Steigerung der Realitätsnähe der Präsentation.
|
|
|
|
6. Um möglichen technischen Problemen vorzubeugen, ist es ratsam, einen Backup-Plan zu haben, wie zum Beispiel die Aufnahme eines Videos der Präsentation, das im Notfall abgespielt werden kann.
|
|
|
|
- Schlussfolgerung: Wichtige Erkenntnisse zu Ticketing als Use Case, Rollen und NFTs, Projektmanagement und Teamarbeit gewonnen.
|
|
|
|
- Zukünftige Arbeiten: Das was wir haben, aber auch Themen wie, Skalierung auf 10.000 Events und viele Benutzer. Es sollte einfach relevant für unser Projekt sein und unsere Application hervorheben.
|
|
|
|
|
|
|
|
Wichtig:
|
|
|
|
- Üben, Üben, Üben :point_up:
|
|
|
|
- Üben der Live-Demo
|
|
|
|
- Erklärungen für Begriffe wie "Smart Contracts" und andere relevante Begriffe für Nicht-Experten, insbesondere im Bereich der Blockchain.
|
|
|
|
- Fragen und Antworten: Vorbereitung auf mögliche Fragen.
|
|
|
|
|
|
|
|
Ablauf:
|
|
|
|
- Nicht alle Aspekte müssen komplett beschrieben werden. Die Sachen haben was auch relevant für uns ist.
|
|
|
|
- Nicht jeder muss vortragen. Das können wir entscheiden, wie es für uns am besten passt.
|
|
|
|
- Vortrag: 25 Minuten (wenns es 30 werden ist es auch okay, bei 35 werden wir gestoppt).
|
|
|
|
- FAQ: ist extra (5 bis 10 Minuten).
|
|
|
|
- Insgesamt mit Auf- und Abbau 45 Minuten pro Gruppe. |