feature/calcDateTimeLogic #3

Merged
kevin merged 6 commits from feature/calcDateTimeLogic into feature/firstrelease 2026-05-03 21:09:55 +00:00
Owner
No description provided.
Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
- main() auf monatsbasierte Iteration umgebaut
- Wochentag wird numerisch per date +%u ermittelt (locale-unabhängig)
- day_map[] als globales Array für numerisch → Wochentagnamen Mapping
- KW-basierte Pool-Rotation bleibt erhalten, jetzt pro Kalendertag berechnet
- get_meal_index() ersatzlos entfernt (Logik inline in main())
- Komponenten-Verarbeitung (@, %) direkt in main() integriert
- declare -A meals / recipe_ids / day_map global verschoben (waren lokal in check_deps)

Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
Author
Owner

Von Claude:
Schau ich mir an! Insgesamt ein ordentlicher Refactor – die Kernidee (von wochentag-basiertem Mapping zu monatsweiser Iteration) macht Sinn. Hier meine Anmerkungen:
Gut gelöst:

declare -A nach oben gezogen – richtig, die source-Calls überschreiben sonst die Deklaration
validate_recipes_id Tippfehler (recipe_id → recipe_ids) gefixt
Payload-Keys korrigiert (plan_date→day, servings→recipe_servings/product_amount) – sieht aus als wärst du da der API-Doku gefolgt, gut
add_group_meal Refactor mit $RANDOM % count ist klarer als das random-in-jq Konstrukt
Die erklärenden Kommentare sind ausführlich – wirkt fast wie Lernprojekt, macht das Lesen jedenfalls angenehm

Potenzielle Probleme:
local in Loops – in der main()-Funktion verwendest du local innerhalb der for-Schleife:
bashlocal date_str weekday_num weekday_name kw pool index meal
local ist in Bash gültig innerhalb von Funktionen, aber die Deklaration in jedem Loop-Durchlauf ist unnötig und leicht irreführend. Besser einmal vor der Schleife deklarieren.
log_warn → log_info Downgrade – ich sehe du hast mehrere Warn-Level auf Info gestuft, z.B. "Es sind Updates verfügbar!". Das ist diskutabel – ein verfügbares Update ist eigentlich eine nützliche Warnung, kein reines Info-Event. Wenn dein Logging irgendwo gefiltert wird (z.B. nur WARN+), verlierst du das still.
KW-basiertes Rotation-Modulo – die Logik kw % pool_size als deterministisches Rotation-Schema ist kreativ, hat aber einen Haken: Wochenanzahl pro Jahr variiert (52 vs. 53 Wochen). Wenn ein Jahr 53 Wochen hat und Pool-Größe 2 ist, bekommst du: 53 % 2 = 1, 1 % 2 = 1 – KW1 und KW53 landen auf demselben Gericht, was bei Jahreswechsel zu zwei identischen Wochen hintereinander führt. Ob das stört hängt davon ab wie groß die Pools typischerweise sind – bei 3+ Einträgen unwahrscheinlicher ein Problem.
Minor: doppelte Leerzeile nach add_group_meal (Zeile ~206) – Nitpick, aber du hast sonst einen sauberen Style.
Insgesamt solider Stand. Der log_warn-Punkt und die KW-Rotation würde ich nochmal diskutieren, den Rest würde ich durchwinken.

Von Claude: Schau ich mir an! Insgesamt ein ordentlicher Refactor – die Kernidee (von wochentag-basiertem Mapping zu monatsweiser Iteration) macht Sinn. Hier meine Anmerkungen: Gut gelöst: declare -A nach oben gezogen – richtig, die source-Calls überschreiben sonst die Deklaration validate_recipes_id Tippfehler (recipe_id → recipe_ids) gefixt Payload-Keys korrigiert (plan_date→day, servings→recipe_servings/product_amount) – sieht aus als wärst du da der API-Doku gefolgt, gut add_group_meal Refactor mit $RANDOM % count ist klarer als das random-in-jq Konstrukt Die erklärenden Kommentare sind ausführlich – wirkt fast wie Lernprojekt, macht das Lesen jedenfalls angenehm Potenzielle Probleme: local in Loops – in der main()-Funktion verwendest du local innerhalb der for-Schleife: bashlocal date_str weekday_num weekday_name kw pool index meal local ist in Bash gültig innerhalb von Funktionen, aber die Deklaration in jedem Loop-Durchlauf ist unnötig und leicht irreführend. Besser einmal vor der Schleife deklarieren. log_warn → log_info Downgrade – ich sehe du hast mehrere Warn-Level auf Info gestuft, z.B. "Es sind Updates verfügbar!". Das ist diskutabel – ein verfügbares Update ist eigentlich eine nützliche Warnung, kein reines Info-Event. Wenn dein Logging irgendwo gefiltert wird (z.B. nur WARN+), verlierst du das still. KW-basiertes Rotation-Modulo – die Logik kw % pool_size als deterministisches Rotation-Schema ist kreativ, hat aber einen Haken: Wochenanzahl pro Jahr variiert (52 vs. 53 Wochen). Wenn ein Jahr 53 Wochen hat und Pool-Größe 2 ist, bekommst du: 53 % 2 = 1, 1 % 2 = 1 – KW1 und KW53 landen auf demselben Gericht, was bei Jahreswechsel zu zwei identischen Wochen hintereinander führt. Ob das stört hängt davon ab wie groß die Pools typischerweise sind – bei 3+ Einträgen unwahrscheinlicher ein Problem. Minor: doppelte Leerzeile nach add_group_meal (Zeile ~206) – Nitpick, aber du hast sonst einen sauberen Style. Insgesamt solider Stand. Der log_warn-Punkt und die KW-Rotation würde ich nochmal diskutieren, den Rest würde ich durchwinken.
Signed-off-by: kevin mika <mika.kevin@nexus-6.eu>
kevin merged commit 945d29997d into feature/firstrelease 2026-05-03 21:09:55 +00:00
kevin deleted branch feature/calcDateTimeLogic 2026-05-03 21:09:56 +00:00
kevin referenced this pull request from a commit 2026-05-03 21:09:56 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
kevin/campsupplies!3
No description provided.