- 274 Posts
- 3.34K Comments
9·9 小时前Fixing the typo (‘damage’ instead of ‘damaged’) would’ve gone a long way.
1·9 小时前It’s way too easy to not see the assumptions you make when writing code. Having a mouse, usining a QWERTY layout, screen size over a certain width, … and it’s so fucking annoying to be on the receiving end of these assumptions. I feel you.
For 150 basically random strings I wouldn’t trust AI to not drop one or invent one or slightly change one. In this case multiline editing would be my go-to solution, hands down.
Why 2TB? Why during startup? Why does cryptography free the heap? Why is the data stored off-site?
So many questions!
verwirrend
Auf jeden Fall, keine Frage. Ich hoffe, dass Standardnutzer sich eher an Standardangaben halten, die eher explizit sind und deshalb auch eher erwartungsgemäß verarbeitet werden. Und wer tiefer unter die Haube guckt, findet, dass er sich für die eher erwarteten Anwendungsfälle einige Tastendrücke sparen kann.
Ich glaube, ich versuche gerade mehr, mich zu überzeugen als dich.
Kann es sein, dass du den Kontext vergessen hast? Bei luciferofastora ging es um
anpassen von Skripten nach einer Datenbankmigration um die Schemata und Tabellenamen anzupassen
worauf du „zu viele hart-codierte Strings“ und später „Prepared Statements” geantwortet hast.
Vielleicht hast du bessere Prepared Statements als ich. In meinen kann ich nicht den Tabellennamen konfigurierbar machen.
Den Text zu Zahlen zu machen, ist der schwerere Teil. Sobald ich eine Angabe für jeden der Datumsteile habe, ist es ein Leichtes, daraus das Datum zu bauen.
Der Rest geht auch an @[email protected]:
Mein Anwendungsfall wird ist eine Webseite. Ich will nicht für ein einzelnes Eingabefeld einen Compiler mitliefern, der rekursive Sprachen parsen kann. Ich habe mich schon nach Libraries umgeschaut, aber was ich gefunden habe, entsprach nicht den Anforderungen. Die meisten parsen nur einzelne Datumse (bei mir geht’s um einen Datenbereich) und ich will möglichst reibungsarm in dem sein, was ich von Nutzern akzeptiere. Die Libraries, die ich gefunden habe, sind eher strikt in dem, was sie als gültige Eingabe akzeptieren.
Beispiel: Mit meinem selbstgebastelten Regex kann ich die Eingabe ‘w’ als ‘2026-01-12/2026-01-18’ interpretieren; ‘8.’ als ‘2026-01-08/2026-01-08’ und ‘12.25’ als ‘2025-12-01/2025-12-31’.
Muss das so flexibel sein? Nein. Aber für die Power-User wird das hoffentlich sehr angenehm zu bedienen sein.
Bzw. verwenden deine Skripte zu viele hart-codierte Strings.
Ja, es ist viel besser, dem seltenen Fall, dass sich Tabellennamen ändern, dadurch zu begegnen, indem man seine Tabellennamen in Konstanten auslagert. Das führt garantiert nicht zu Aneurysmen, glaub mir.
const SQL = `SELECT ${CUSTOMER_TABLE_NAME_COLUMN} FROM ${CUSTOMER_TABLE_NAME} JOIN ${TARIFF_TABLE_NAME} USING (${CUSTOMER_TABLE_ID_COLUMN);`
Ganz ehrlich, mit der Dystopie in Schöne Neue Welt kann ich mich abfinden. So gut wie jeder ist glücklich. Ich finde, das sollte das Ziel einer Gesellschaft sein. Und es ist in jedem Fall ein Fortschritt gegenüber dem, was wir jetzt haben.
14·13 小时前Und Ausfälle haben sie auch noch!
Als 2022 die Energieabgabe auf Kraftstoffe gesenkt wurde, gab’s eine kurze, aber nicht erhebliche Senkung der Spritpreise, die sich aber ziemlich schnell wieder in Luft aufgelöst hat.
Wenn die Mehrwertsteuer abgeschafft wird, werden die Preise über drei Monate verschmiert um 7%¹ angehoben. Genau dasselbe, was bei der Reduzierung der Energiesteuer 2022 passiert ist.
Der Markt wird dafür sorgen, dass die Preise so hoch sind, wie es sich die Leute noch leisten können. Wenn 7% erzwungene Ausgaben wegfallen, sind das 7% Mehrgewinn für die Hersteller.
[1] Ich weiß, dass Mathe so nicht funktioniert.
I find it interesting that the translation for Zangendeutsch keeps changing.