knuspermagier.de
Ein L und zwei P. Philipp!

Warum sind alle Rezepte-Apps furchtbar

Eben fragte ich auf Mastodon, was ihr so als Rezepte-Sammlungs-App benutzt. Diese Frage stelle ich regelmäßig und ich bin jedes Mal wieder enttäuscht. Das Problem ist nämlich, dass es tausende Apps, Webapps und analoge Möglichkeiten gibt und, kaum zu glauben, alle sind in furchtbar. Wahrscheinlich ist das auch der Grund, warum es so viele verschiedene Lösungen gibt. Jede Person hat Vorlieben, was das Rezepte-Management angeht und anscheinend ist es dann direkt die zweite App, die man direkt nach der Todo-App anfängt.

Moment Philipp, werdet ihr euch fragen, hast du nicht selber eine Rezepte-App gebaut? Ja, richtig. Hab ich. Leider benutze ich sie nicht, da ich eines Tages angefangen habe, alles umzubauen und schöner zu machen, aber, wie immer, keine Lust mehr hatte, alles liegen ließ und nun funktioniert die Hälfte nicht mehr. Natürlich könnte ich sicher alles per Git auf einen funktionierenden Stand reverten, aber zwischendurch gab es auch Datenbank-Änderungen und alles ist schlimm. Das klassische neglected Sideproject, das man eigentlich endlich mal in die Restmülltonne kehren sollte, damit es nicht ständig mentale Energie verbraucht.

Genau das möchte ich ja tun, aber ich finde einfach nichts, was passt. Ich habe ja gar nicht so viele Wünsche:

  • Es soll halbwegs ansprechend aussehen, kein Webinterface mit Material UI.
  • Tags oder Ordner zum Sortieren.
  • Zutaten sollten eigene Entities im System sein, ich möchte nach Zutaten filtern, und alle Rezepte die rote Zwiebeln verwenden, sollen auf die gleiche Entity zeigen und nicht auf “Zwiebeln (rot)” und “rote Zwiebeln” und “Zwiebel, rot”.
  • Beim Anlegen neuer Rezepte möchte ich einen Autocomplete bei den Zutaten.

Folgende i-Tüpfelchen hätte ich noch:

  • Es gibt eine iOS-App und eine Mac-App, die Daten per CloudKit speichern, sodass ich die Rezepte per CloudKit-Sharing im Haushalt teilen kann, ohne, dass ich einen Account beim Hersteller der Rezepte-App brauche.
  • Wochenplan-Funktion, wo ich aber nicht nur Rezepte eintragen kann, sondern auch Freitexte
dalle-2023-01-22-00.09.38-man-with-long-brown-curly-hair-sitting-in-front-of-a-laptop-and-is-desperately-looking-at-screenshots-.png
man with long brown curly hair sitting in front of a laptop and is desperately looking at screenshots of recipe manager apps, digital art

Folgende Sachen habe ich in den letzten Wochen angeguckt oder ausprobiert:

  • Nextcloud Cookbook (via alerich) — Guckt es euch nicht an, es sieht furchtbar aus. Außerdem werde ich dafür kein Nextcloud installieren.
  • Mela (via Don, hatte ich aber auch vorher schon probiert) — Ist an und für sich ziemlich gut, auch mit i-Tüpfelchen, aber Zutaten sind nur ein großes Freitext-Feld.
  • Mealie (via Sebastian) — MaterialKotzUI. Habe es mir nicht genau angeschaut, aber auf den Screenshots sieht die Editieroberfläche aus wie bei mir, Zutaten sind also Entities. Nice. Leider sieht es halt wirklich schlimm aus.
  • Crouton (via Andreas, hatte es aber auch schon vor Monaten probiert) — Davon war ich, als ich es neu fand, oder auch von jemandem empfohlen bekam, richtig stark begeistert. Schön schlichtes Design, CloudKit. Leider, ihr ahnt es, keine vernünftigen Zutaten. Die Mac-App sah auch dumm aus.
  • Bring! (via Maurice) — sieht furchtbar aus. Ich hab mir das Rezepte-Feature nichtmal angeguckt, weil die App gezwungenermaßen einen Account braucht.
  • körbchen und Pestle — diese beiden Apps mit dummen Namen habe ich im App Store gefunden, installiert, drei Sekunden angeguckt und gelöscht, ich weiß gar nicht mehr, was mich im Detail störte.
  • Paprika — Ist ja die bekannteste Rezepte-App aber das Design kickt mich auch echt gar nicht. Und ich fand auf der Webseite jetzt auch keine Sharing-Funktionalität mit mehreren Benutzern? Haben die das echt nicht?

Wie man sieht, alle Apps sind furchtbar, inklusive meiner Eigenen. Ich kann’s ja auch ein bisschen verstehen. Zutaten als eigene Entity ist schwer und macht ein riesiges Fass auf. Ist eine gelbe Paprika eine andere Zutat als eine rote Paprika, oder sind es beides Paprika nur mit einem Modifier? Wenn man Lust auf Datenmodellierung hat, kann man da sicherlich Wochen zubringen. Oder man macht die Zutaten einfach als großes Freitextfeld, weil 99% der Leute eh Rezepte von Chefkoch.de importieren und es allen egal ist, dass die Daten völlig unkonsolidiert sind.

Was ich nun mache? Keine Ahnung. Ich denke, trotz allem kann ich eher mit der Zutaten-Situation leben, als damit, MaterialUI anzuschauen, daher werde ich wohl meine Daten mal in Mela importieren und meine Webapp endlich entsorgen. Auch wenn es mir beim Schreiben dieses Satzes schon weh tut.

Falls noch jemand, unerwarteterweise, eine bessere Empfehlung hat, lasst es mich bitte wissen.

(Auch wenn ich in diesem Post eindrucksvolle Wörter wie “furchtbar” und “kacke” verwende möchte ich herausstellen, dass es sich hier lediglich um ein pet peeve handelt und ich nicht den lieben langen Tag darüber traurig bin, dass es keine Rezepte-App gibt, die mir gefällt, oder dass jemand MaterialUI erfunden hat. Wobei letzteres wirklich Potential dazu hätte)

Kirby x Laravel x Cannot redeclare e()

Ich hatte über das Problem ja schon einmal berichtet – wenn man Kirby zusammen mit verschiedenen Laravel-Sachen benutzen will, bekommt man oft diese Fehlermeldung:

Fatal error: Cannot redeclare e() (previously declared in vendor/illuminate/support/helpers.php:109) in vendor/getkirby/cms/config/helpers.php on line 130

Das Problem ist, dass sowohl Laravel als auch Kirby ein paar Helper-Funktionen definieren, unter anderem eine, die e heißt. Leider hat Kirby in seiner Deklaration keine function_exists-Abfrage und dadurch explodiert alles. Ich hatte sogar schonmal im Kirby-Discord nachgefragt, warum das so ist – man will hier vermeiden, dass eine Helper-Funktion, von einem random Composer-Package überschrieben wird, das gegebenenfalls etwas komplett anderes macht und damit die Funktionalität der Seite kaputt macht. Fair enough.

Nervig ist es trotzdem.

Man kann die Sache umgehen, in dem man in der public/index.php folgendes ergänzt:

define('KIRBY_HELPER_E', false);

Letztens wollte ich allerdings mal ein paar coole Sachen in mein immer wachsendes Kirby-Projekt hinzufügen, namentlich phpunit, phpstan und phpcs. Natürlich haben all diese Tools das exakt gleiche Problem. Leider lässt es sich nicht so leicht lösen, wie für Kirby, denn die Tools lesen natürlich nicht zuerst die public/index.php ein. Je nachdem gibt es zwar ein paar Optionen, um gewissen Code vorher auszuführen, aber ich fand nichts, was wirklich universell gut klappte.

Zum Glück fand ich jetzt in einem Github-Issue auf das composer-include-files-Plugin aufmerksam wurde. Die Funktion ist sehr übersichtlich: Es sorgt einfach dafür, dass die Dateien, die man in der composer.json angeben kann, als allererstes im Autoloader ausgeführt werden.

Das heißt, ich kann die tolle Konstante für Kirby ganz am Anfang ausführen und auch alle externen Tools, die den Code parsen, verstehen das. Wunderbar.

Damit ist jetzt hoffentlich dieses furchtbare Problem, über das ich immer wieder gestolpert bin, ein für alle Mal gelöst.