github-classroom[bot]
1 year ago
committed by
GitHub
commit
6147d2e858
@ -0,0 +1,129 @@
|
||||
# Byte-compiled / optimized / DLL files
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
|
||||
# C extensions
|
||||
*.so
|
||||
|
||||
# Distribution / packaging
|
||||
.Python
|
||||
build/
|
||||
develop-eggs/
|
||||
dist/
|
||||
downloads/
|
||||
eggs/
|
||||
.eggs/
|
||||
lib/
|
||||
lib64/
|
||||
parts/
|
||||
sdist/
|
||||
var/
|
||||
wheels/
|
||||
pip-wheel-metadata/
|
||||
share/python-wheels/
|
||||
*.egg-info/
|
||||
.installed.cfg
|
||||
*.egg
|
||||
MANIFEST
|
||||
|
||||
# PyInstaller
|
||||
# Usually these files are written by a python script from a template
|
||||
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
||||
*.manifest
|
||||
*.spec
|
||||
|
||||
# Installer logs
|
||||
pip-log.txt
|
||||
pip-delete-this-directory.txt
|
||||
|
||||
# Unit test / coverage reports
|
||||
htmlcov/
|
||||
.tox/
|
||||
.nox/
|
||||
.coverage
|
||||
.coverage.*
|
||||
.cache
|
||||
nosetests.xml
|
||||
coverage.xml
|
||||
*.cover
|
||||
*.py,cover
|
||||
.hypothesis/
|
||||
.pytest_cache/
|
||||
|
||||
# Translations
|
||||
*.mo
|
||||
*.pot
|
||||
|
||||
# Django stuff:
|
||||
*.log
|
||||
local_settings.py
|
||||
db.sqlite3
|
||||
db.sqlite3-journal
|
||||
|
||||
# Flask stuff:
|
||||
instance/
|
||||
.webassets-cache
|
||||
|
||||
# Scrapy stuff:
|
||||
.scrapy
|
||||
|
||||
# Sphinx documentation
|
||||
docs/_build/
|
||||
|
||||
# PyBuilder
|
||||
target/
|
||||
|
||||
# Jupyter Notebook
|
||||
.ipynb_checkpoints
|
||||
|
||||
# IPython
|
||||
profile_default/
|
||||
ipython_config.py
|
||||
|
||||
# pyenv
|
||||
.python-version
|
||||
|
||||
# pipenv
|
||||
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
||||
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
||||
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
||||
# install all needed dependencies.
|
||||
#Pipfile.lock
|
||||
|
||||
# PEP 582; used by e.g. github.com/David-OConnor/pyflow
|
||||
__pypackages__/
|
||||
|
||||
# Celery stuff
|
||||
celerybeat-schedule
|
||||
celerybeat.pid
|
||||
|
||||
# SageMath parsed files
|
||||
*.sage.py
|
||||
|
||||
# Environments
|
||||
.env
|
||||
.venv
|
||||
env/
|
||||
venv/
|
||||
ENV/
|
||||
env.bak/
|
||||
venv.bak/
|
||||
|
||||
# Spyder project settings
|
||||
.spyderproject
|
||||
.spyproject
|
||||
|
||||
# Rope project settings
|
||||
.ropeproject
|
||||
|
||||
# mkdocs documentation
|
||||
/site
|
||||
|
||||
# mypy
|
||||
.mypy_cache/
|
||||
.dmypy.json
|
||||
dmypy.json
|
||||
|
||||
# Pyre type checker
|
||||
.pyre/
|
||||
@ -0,0 +1,126 @@
|
||||
**Achtung dies ist eine Hausarbeit als Gruppenaufgabe.**
|
||||
|
||||
# Hausarbeit als Prüfungsleistung WiSe 2022/2023
|
||||
|
||||
Bitte den gesamten Text aufmerksam durchlesen und erst dann mit der Aufgabe anfangen. Fragen bitte im Discord oder Labor klären.
|
||||
|
||||
# Aufgabe
|
||||
|
||||
*Abgabe bis 02.01.2023 23:00:00.00000*
|
||||
|
||||
Aufbauend auf den Laboraufgaben 5 und 6 soll die Mensa-Anwendung um ein Userinterface zum Eingeben von Menüs, zum Verwalten von Standorten und News für die Standorte erweitert werden.
|
||||
|
||||
## Bewertungskriterien
|
||||
|
||||
- 60 % der Note ergeben sich aus der Erfüllung der funktionalen Anforderungen
|
||||
- 20 % der Note ergeben sich aus der Einhaltung der nicht-funktionalen Anforderungen
|
||||
- 20 % der Note ergeben sich aus der Präsentation der Ergebnisse
|
||||
|
||||
## Funktionale Anforderungen
|
||||
|
||||
### Aus Laboraufgabe 5
|
||||
|
||||
Die Daten werden von https://mensa.fly.dev abgerufen (API).
|
||||
|
||||
* Es sollen die Speisepläne beider Mensen gemeinsam angezeigt werden können
|
||||
* Es soll nach Vegan (vn) oder Vegeratisch (vg) gefiltert werden können
|
||||
* Es soll die gesammte Woche angezeigt werden können
|
||||
* Die Auswahl der Filter soll gespeicher werden können
|
||||
* Für Gruppen mit 5 Mitgliedern: Es soll ausgewählt werden können, welcher der drei Preise angezeigt werden soll (Studierende / Hochschulangehörige / Gäste)
|
||||
|
||||
Beispiel, wie es aussehen könnte: https://mensafrontend.fly.dev/
|
||||
|
||||
**Wer diese Aufgabe nicht gemacht hatte, weil er den Laborschein schon hatte, muss diesen Teil für die Hausarbeit nur soweit nachholen, wie er für die neue Aufgabe gebraucht wird (nur der erste Bulletpoint)**
|
||||
|
||||
### Aus Laboraufgabe 6
|
||||
|
||||
* Gerichte sollen kommentiert werden können (vorest von anoymen Nutzern, d.h. ohne Anmeldung). Zu den Gerichten sollen dann diese Kommentare angezeigt werden (Text, Datum, Nutzerpseudonym).
|
||||
* Für Gruppen mit mehr als 3 Mitgliedern: Gerichte sollen geliked werden können, so dass die Anzahl likes zu den Gerichten angezeigt wird.
|
||||
|
||||
**Wer dise Aufgabe nicht gemacht hatte, weil er den Laborschein schon hatte, muss diesen Teil für die Hausarbeit nicht nachholen**
|
||||
|
||||
### Neue Funktionale Anforderungen für die Hausarbeit
|
||||
|
||||
1. Essen soll auch von Hand angelegt werden können.
|
||||
|
||||
* Das Datenmodell soll die Daten, wie sie auch aus der API kommen (https://mensa.fly.dev) abbilden
|
||||
* Es soll Create, Retrieve, Update und Delete (CRUD) Routen und Views geben (Create = List und Detail)
|
||||
* Es soll auf Nutzerwunsch weiterhin möglich sein, von der API Daten abzurufen
|
||||
|
||||
2. Die Essen sollen Standorten zugeordnent sein, die auch von Hand angelegt und bearbeitet werden können (CRUD)
|
||||
3. Für Standorte sollen News hinterlegt werden können (CRUD), die dann den Nutzern, wenn sie einen Standort auswählen, angezeigt werden, zusätzlich zu den Essen.
|
||||
|
||||
Pro Anforderung werden 20 Punkte maximal vergeben. Dabei Teilen sich die Punkte jeweils wie folgt auf die Umsetzung von CRUD auf:
|
||||
|
||||
* Max. 5 Punkte für Create
|
||||
* Max. 8 Punkte für Retrieve (Liste und Details jeweils 4 Punkte)
|
||||
* Max. 5 Punkte für Update
|
||||
* Max. 2 Punkte für Delete
|
||||
|
||||
So können mit den funktionalen Anforderungen max. 60 Punkte von 100 erreicht werden.
|
||||
|
||||
**Hinweise:**
|
||||
|
||||
* Nutzeranmeldung, Rechte usw. können ignoriert werden
|
||||
* Der Django-Admin kann zwar genutzt werden, ersetzt aber nicht die Anforderung zu CRUD (ihr sollt das selbst bauen)
|
||||
|
||||
## Nicht-Funktionale Anforderungen
|
||||
|
||||
1. Nutzt, wo es geht und sinnvoll ist, klassenbasierte Views
|
||||
2. Wenn Routen mit IDs aufgerufen werden, die nicht vorhanden sind, soll eine 404-Error-Seite angezeigt werden
|
||||
3. Es soll eine eigene Django-App geben (`python manage.py startapp ...`), also nicht die Views direkt in das Projekt packen. Auch sonst soll eine übliche und sinnvolle Projektstruktur eingehalten werden
|
||||
4. Funktionen, Klassen und Module sollen mit aussagekräftigen Kommentaren / docstrings (https://peps.python.org/pep-0257/) versehen sein
|
||||
5. Templates sollen auf ein gemeinsames Basis-Template aufbauen und Blöcke nutzen
|
||||
6. Die Abhängigkeiten sollen über eine requirements.txt gemanaged werden
|
||||
7. Die Anwendung soll optisch einigermaßen ansprechend sein (CSS-Frameworks sind erlaubt)
|
||||
8. Code-Duplication soll vermeiden werden
|
||||
9. Der Code soll "sauber" sein, z.B. sinnvolle Variablennamen, keine unnötigen Indizes bei Schleifen über Listen, keine ungenutzten Importe, generell kein ungenutzter Code
|
||||
|
||||
Für die Punkte 1. - 8. gibt es jeweils max. 2 Punkte. Für den Punkt 9. gibt es maximal 4 Punkte. So können mit den nicht-funktionalen Anforderungen max. 20 Punkte von 100 erreicht werden.
|
||||
|
||||
## Präsentation der Ergebnisse
|
||||
|
||||
Vorstellung 15 - 20 min im Labor in der ersten Januarwoche (alle Gruppenteilnehmer\*innen beteiligt an der Vorstellung; geht auch über Discord).
|
||||
|
||||
Die Laborgruppe von Montag bekommt den Vorlesungszeitslot zur Vorstellung, die anderen Gruppen stellen zu ihrer normalen Laborzeit vor.
|
||||
|
||||
Es gibt jeweils max 5 Punkte für:
|
||||
|
||||
* Einhaltung des Zeitkontingents
|
||||
* Visuelle Präsentation
|
||||
* Aufbau der Präsentation
|
||||
* Inhalt
|
||||
|
||||
So können für die Präsentation maximal 20 Punkte von 100 erreicht werden.
|
||||
|
||||
# Bildung der Note aus den Punkten
|
||||
|
||||
```
|
||||
Prozent (Punkte) Note
|
||||
100 - 94 % 1,0 sehr gut
|
||||
<94 - 89 % 1,3 sehr gut (-)
|
||||
<89 - 84 % 1,7 gut (+)
|
||||
<84 - 79 % 2,0 gut
|
||||
<79 - 73 % 2,3 gut (-)
|
||||
<73 - 68 % 2,7 befriedigend (+)
|
||||
<68 - 63 % 3,0 befriedigend
|
||||
<63 - 57 % 3,3 befriedigend (-)
|
||||
<57 - 52 % 3,7 ausreichend (+)
|
||||
<52 - 50 % 4,0 ausreichend
|
||||
<50 % 5,0 nicht bestanden
|
||||
```
|
||||
|
||||
## Hinweis bei ungleich verteilter Leistung der Gruppenteilnehmer
|
||||
|
||||
Es besteht ein Anspruch auf eine individuelle Benotung. Zur Feststellung der individuellen Leistungen können herangezegen werden:
|
||||
|
||||
1. Git: Commits, Teilnahme an Diskussionen von Issues usw.
|
||||
2. Anteil an der Präsentation
|
||||
3. Aussage der anderen Gruppenteilnehmer
|
||||
|
||||
Sollte ein Gruppe das Gefühl haben, dass einzelne Mitglieder sich nicht an der Gruppenleistung beteiligen, wäre zu bevorzugen, wenn die Gruppe dies zunächst intern einvernehmlich klärt und das Gruppenmitglied zu Mitarbeit bewegt. Ansonsten sollte die Gruppe sich bitte frühzeitig an mich (niklas.klein@hs-flensburg.de) wenden, damit das geklärt werden kann.
|
||||
|
||||
Im Zweifel können einzelnen Mitglieder durchfallen, die sich nachweislich nicht beteiligt haben!
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in new issue