programmiermethoden-campusminden / prog2-lecture Goto Github PK

Für die deutschsprachigen Einträge wird nur das erste Word des Titels korrekt im Literaturverzeichnis wiedergegeben, die restlichen Wörter werden alle (teilweise fälschlich) klein geschrieben.

see https://pandoc.org/MANUAL.html#capitalization-in-titles

Mögliche Lösung: jgm/pandoc#8209 (comment)

langid = {de}
langid = {en}

zu jedem Eintrag hinzufügen.

Update: Man kann analog zu Bibtex die Titel mit doppelten geschweiften Klammern schützen. Sobald aber dann eine gemischte Schreibweise vorliegt, packt Pandoc ein [...]{.nocase} um den Titel dazu, was Hugo dann wieder nicht versteht.

Wir haben unsere Organisation "PM-Dungeon" und das Vorlesungs-Repo "Lecture" genannt. Das passt auch eigentlich ganz gut.

Aber mir ist kürzlich aufgefallen, wenn Studis sich das Repo forken, dass dann der Fork im Studi-Repo auch einfach nur "Lecture" heisst, was nicht besonders aussagekräftig ist.

Mein Vorschlag ist, dass wir den Namen für das Lecture-Repo nochmal überdenken. Vielleicht "PM-Lecture" (bestes denglisch)?

@AMatutat @Tobias321 Was denkt Ihr?

zusätzlichen PDF-Export anbieten

Spring Boot ist ja ein recht populäres Framework im Java-Bereich.

• Macht es Sinn, das in eine Lehrveranstaltung mit Java-Fokus zu integrieren?
• Ist es evtl. zu komplex für ein zweites Semester?
• Ist es evtl. zu komplex für 1..2 Blöcke a 15..20 Minuten?
• Wird es im Studium schon an anderer Stelle besprochen?

• Einsatz des Wikis für die Skripte (?)
• Einsatz von Jupyter-Skripten als Skripte (?)
• Hugo-Templates mit Pandoc nachbauen (?)
• Anderes Hugo-Theme (?)
• Anderen Seitengenerator (mkDocs, mdBook, ...)?

see https://github.com/PM-Dungeon/pmdungeon-html/issues/18#issuecomment-950134772

Wiki:
naja, das rendering findet quasi ausschließlich in github statt, es gibt ein rudimentäres menü und ein rudimentäres toc für jede seite. ansonsten halt die markdown-ansicht wie auch im normalen repo. andererseits gibt es keine "richtige" versionskontrolle und auch keine anzeige von contributors etc. ...

Jupyter:
ich bin neulich mal über ein projekt eines kollegen im saarland gestolpert: https://github.com/uds-se/fuzzingbook ... der schreibt initial alles in jupyter-notebooks und hat eine toolchain, die das in folien (reveal.js mit nettem style) plus markdown plus html für eine webseite übersetzt. der witz ist aber, dass github diese jupyter-notebooks bereits relativ "schön" anzeigt: mathe wird sauber gerendert etc. (beispiel: https://github.com/uds-se/fuzzingbook/blob/master/notebooks/Grammars.ipynb oder https://github.com/uds-se/fuzzingbook/blob/master/notebooks/ProbabilisticGrammarFuzzer.ipynb) ... das bringt mich angesichts dieser unklaren situation, ob nun eine datenschutzerklärung notwendig ist oder nicht und wenn ja, was genau da rein muss, ins nachdenken. man könnte mit pandoc plus einem ci-workflow aus dem markdown die jupyter-notebooks erzeugen und die in einem seitenbranch einchecken (lassen). diese notebooks können sich die studis direkt im github/browser ansehen (inkl. code, abbildungen, mathe) und auch runterladen und als notebook ausführen (also mit den code-snippets interaktiv rumspielen). dann könnte man sich die webseite und den ganzen stress dazu sparen. zumal die toolchain md > pandoc > md > hugo > html sich in der praxis als erstaunlich anfällig zeigt :/

das einzige, was mir da fehlt, sind (a) ein menü über alle seiten und (b) ein toc/navigation in einer seite. aber (a) könnte man durch gliederungsseiten ohne probleme selbst manuell nachbauen und (b) geht vermutlich auch, man muss es sicher nur aktivieren (pandoc beispielsweise kann auch markdown mit toc erzeugen, aber das muss man ihm erst sagen). für die pandoc-webseite wird sowas ähnliches gemacht (siehe https://github.com/jgm/pandoc-website/blob/master/Makefile).

Alternative: Hauptrepo mit Unterlagen und Quizzes und Sourcen etc., automatische Generierung der Pages als HTML (https://github.com/pandoc-scholar/pandoc-scholar) oder Jupyter (https://github.com/uds-se/fuzzingbook). Je Semester ein neues Repo, dort Syllabus und Grading etc. in Markdown only und Schedule manuell mit Links in YT/FH-Medien plus Hauptrepo (gh-pages) für einzelne Lectures. Dann wird kein Menü o.ä. gebraucht und man hat eine schlanke Lösung, und im Hauptrepo hat man nicht die Vermischung aus Inhalten und Orga-Kram. Zusätzlich können im Semester-Repo die Issues und Discussions für die Kommunikation genutzt werden.

Pandoc:

• Pages mit eigenem Template (Make plus Pandoc-Template)
• Navigation in Page mit TOC (Export mit --toc-Option)
• Navigation über alle Pages mit Menü
• Konfigurierbarer Schedule

• #114
• #115
• #107

Die Aufgabenblätter für die Aufgaben IM Dungeon müssen überarbeitet/erstellt werden.
Dafür sollten wir uns auf einen Ablauf einigen.

Idee 1 Klassisch:

• regelmäßige Arbeitsblätter mit fester Struktur (Blatt 1 -> Blatt 2-> ... -> letztes Blatt"
• pro:
  • bekannt
  • klare Struktur
  • klarer Zusammenhang zwischen dem Thema der Vorlesung und dem Praktikum (jeweils aus der gleichen Woche)
  • einfacher für die Tutoren
• con:
  • sehr statisch
  • keine Flexibilität welche Technik für welches Problem genutzt wird,

Idee 2 Aufgabenpool:

• die Aufgaben werden als ein großer Pool zur Verfügung gestellt und die Studis können die Aufgaben in jeder beliebigen Reihenfolge abarbeiten
• pro:
  • Die Studis müssen selbst auf die Idee kommen, welche Technik für welche Aufgabe am besten geeignet ist
  • Flexibilität für die Studis
  • Abwechslungsreichere Lösungen
• con:
  • größere Korrekturanforderung an die Tutoren
  • keine Technik als Vorgabe. Was ist, wenn jemand alle Aufgaben auf die "dümmste" Weise umsetzt?
  • Wie viele Aufgaben pro Woche? Manche Features sind komplexer/aufwendiger als andere.
    • könnte man da mit einem Werte-System arbeiten? Jede Aufgabe bekommt, abhängig vom Aufwand, einen Wert und jede Woche müssen Aufgaben gemacht werden, die zusammen einen Wert x haben.

Andere Fragen:

• wollen wir das Projekt am Ende des Semesters beibehalten?
• Lerntagebuch?
• In Sysprog haben wir über "Konzept-Abnahmen" gesprochen. Können/wollen wir das auch integrieren? Wird das evtl. zu viel? Dann hätten wir Trockenübung, Konzept und Dungeon.

Welche Themen soll es in PM geben, ggf. welche Unterthemen? Welche existieren bereits, welche müssen neu erstellt werden? Welche Länge wird jeder Block haben?

Siehe https://github.com/PM-Dungeon/Lecture/wiki/Themen

siehe auch #182

Update: Excel im Branch planung (siehe PR #184)

Die Aufgaben aus dem Pool A müssen erstellt werden

• #67
• #68
• #69
• #70
• #71

• Prüfen: Ist das wirklich ein normales Pattern?
• Neues 10-Minuten-Mopped für VL (Tabelle updaten)

Update: Lt. "Game Programming Pattern" gibt es ein "Command"-Pattern. "Flyweight" und "Type Object" sind in unserem Kontext evtl. auch ganz interessant ...

Die Aufgaben für Pool B müssen erstellt werden

• #72
• #73
• #74
• #75
• #76
• #77
• #78
• #79

Das Factory-Pattern würde sich perfekt für die Erzeugung von Monstern eignen.
Die MonsterFactory schaut sich an, welches Design aktuell verwendet wird und wie weit fortgeschritten der Spieler ist (je weiter, desto stärker die Monster) und schmeißt dann die entsprechenden Monster raus.

Ich hab keinen aktuellen Plan zur Hand, daher weiß ich nicht, ob und wann das Pattern Bestandteil der Vorlesung ist. Am alten Praktikum orientiert, wäre Blatt 02 das Blatt mit den Monstern.

Das aktuelle Docker-Image ist für amd64. Um den Container auch auf M1 laufen lassen zu können, sollte das Image als Multi-Arch-Image gebaut werden und zusätzlich arm64 beinhalten.

Vgl. https://docs.docker.com/desktop/multi-arch/ und https://stackoverflow.com/questions/68975743/docker-image-runs-on-intel-mac-but-not-m1-mac

Caching des Images (Beschleunigung des Builds): Beispiele siehe pandoc/pandoc-action-example#23

Die Aufgaben für Pool C müssen erstellt werden

• #80
• #81
• #82
• #83
• #84
• #85
• #86
• #87
• #88

In alle drei Pools A, B und C gibt es je eine freie Aufgabe mit 10P.

• Der Beschreibungstext sollte deutlich machen, dass sich die Studis hier "austoben" dürfen.
• Es sollte ein oder zwei Beispiel-Ideen geben, damit die Studis eine Idee des gewünschten Umfangs bekommen.
• Es sollte deutlich werden, dass hier keine bereits existierenden Aufgaben und auch keine bereits abgegebenen Aufgaben bearbeitet werden können, sondern dass es um neue Ideen geht.

Update:

• Für die Projekt-Seite könnte direkt assignments/pool_p/_index.md genommen werden, da es darunter nur eine einzige Seite mit der Projektbeschreibung gibt
• Spätestens eine Woche vor Projekt: Im Praktikum Pitch mit Jonas diskutieren
  • Konzept/Pitch kann mdl. sein, dient vor allem der Machbarkeit und Aufwandsabwägung
  • 10P für inhaltliche Dinge absprechen
• Erste Woche: Feinkonzept, Grundgerüst/Grobimplementierung
  • 10 Punkte für Feinkonzept und Grundimplementierung: TBD
• Zweite Woche: Implementierung, Dokumentation, Lerntagebuch
  • Inhaltliche Punkte für Umsetzung
  • Punkte für schriftliche Ausarbeitung: Kriterien TDB
  • Abzüge wie bei den Dungeon-Aufgaben sonst

=> erstes Projekt: entweder in der Woche vor dem E-Assessment oder in der Woche mit dem E-Assessment

Sowohl für die Konzeptaufgaben als auch für die Dungeonaufgaben wird ein festes Template benötigt.

Für alle Typen:

• Name/Überschrift
• Aufgabenstellung
• Punkte

Für Dungeonaufgaben

• Angabe zu welchen Pool das gehört

Für Konzeptaufgaben:

• ggf. verweis auf Vorgaben
• Abgabedatum

@cagix Für Hugo/Pandoc wird vermutlich ein festes Format benötigt, oder?

Die verschiedenen Aufgaben müssen formuliert werden.

• #63
• #64
• #65
• #66
• #320
• #89
• #90

• Repo: "PM-Lecture"
• Readme.md: Link zu den Contributors
• static/license.html: Link zu den Contributors
• static/license.html: Link auf das Repo
• config.yaml: Link auf die GH-Page
• config.yaml: editURL
• Zusätzlich noch einmal "grep" nach dem alten Repo-Namen
• Lokale Workingcopy: git remote set-url origin <neuer pfad>

follow up of #50

Bitte schöne Namen für die Konzeptübungen sammeln.

• Die Pfade zu den Pages tauchen mehrfach auf: Makefile, Schedule, ... Prüfen, ob sich das Makefile vereinfachen lässt, und ob die Auflistung der Files für die Pandoc-Vorverarbeitung wirklich notwendig ist
• Targets überarbeiten, damit Dinge tatsächlich nur bei Bedarf neu übersetzt werden
• Alle .md mit Pandoc vorverarbeiten (?)

edit: ist in Makefile aus https://github.com/Compilerbau/Lecture gelöst

@jposselt Kannst Du bitte das Makefile aus https://github.com/Compilerbau/Lecture hier als Pull-Request einkippen? Da hast Du viel Zeit reingesteckt, also solltest Du auch hier als Author auftreten!

Wir haben einen ziemlich großen Pool an alten Aufgaben, dieser sollte begutachtet werden und die einzelnen Aufgaben zu den entsprechenden Vorlesungsthemen zugeordnet werden.

• Recherche: Können Hugo-related Ordner verschoben werden? Wo/Wie sieht die Konfiguration aus?
• Schiebe alle Hugo-related Ordner in den neuen Unterordner hugo/
• Achtung: da sind drei Git-Submodules dabei (einfach verschieben reicht nicht)
• Config für Hugo anpassen

• #101
• #102
• #103

duplicate of #346

"deploy-to-abgabe": neben dem framework von nelson bin ich neulich über das hier gestolpert: "code freak" (paper, github). klingt wie ein "richtiges" framework und wird scheinbar bereits relativ breit an der uni kiel eingesetzt ...

• #104
• #109

Die verschiedenen Konzeptaufgaben müssen erstellt werden

• #91
• #92
• #93
• #94
• #95
• #96
• #97
• #98
• #99
• #100

Die Metadaten für die Aufgaben müssen überprüft und ggf. angepasst werden.

• Stimmen die Punkte?
• Autor?
• ggf. Abgabedatum (wird über data/schedule.yaml definiert)
• Gewichtung