Was ein netter Nachmittag mit Kokain und Programmieren werden sollte, ist zu zwei Tagen Arbeit ausgeartet. Und der schlimmste Teil war, die Benutzerdoku zu schreiben!

    • yetAnotherUser ( yetAnotherUser@discuss.tchncs.de ) 
      5·
      il y a 9 mois

      Mein Problem ist es schnell und einfach HTML zu scrapen und parsen.

      Die Lösung? curl "$URL" | grep -E "$REGEX" | sed 's|"$OLD"|"$NEW"|' offensichtlich!

      (Keine Sorge, es ist etwas “schöner”. Hier ein wunderschöner Ausschnitt:)

      Äußerst legitime Anwendung von Regex die ich tatsächlich so eingebaut habe 
      old_file=$(find . -maxdepth 1 -regextype egrep -regex '\./'"$filename"' [0-9]{4}-[0-9]{2}-[0-9]{2}\..*' -print | sort | tail -n1 | sed 's|\./||')

      Dokumentation wäre hierfür überflüssig.

    • luciferofastora ( luciferofastora@feddit.org ) 
      3·
      il y a 9 mois

      Wenn mein Problem ist, dass ich in einer Datei einen häufigen regelmäßig geformten Ausdruck finden und durch einen anderen ersetzen will?

      Ein Beispiel wäre anpassen von Skripten nach einer Datenbankmigration um die Schemata und Tabellenamen anzupassen (ja, die neue Datenbank hat Tabellenamen verändert).

        • luciferofastora ( luciferofastora@feddit.org ) 
          3·
          il y a 9 mois

          Dann brauchst du keine regulären Ausdruck, sondern musst Token ersetzen. Da reicht Pattern-Matching.

          Das sagt mir nichts, fürchte ich, aber ich lass mich gerne belehren.

          Bzw. verwenden deine Skripte zu viele hart-codierte Strings.

          Ich geh schon bei jeder Gelegenheit her und isolier alle Folgeabfragen gegen die ursprünglichen Quellen. Die jeweiligen Tabellen werden genau einmal direkt bezeichnet, danach haben sie ein Alias, gerade um so was zu minimieren. (Und weil die ursprünglichen Bezeichnungen beschissen sind, keine Ahnung was die Entwickler da geritten hat. Gleiches Spiel mit den Spalten.)

          Hilft halt nix, wenn ich insgesamt 100 verschiedene Tabellen abfrag, die jeweils irgendwo in Konstanten auszulagern. Das Schema, ja, hätte ich können wenn ich geahnt hätte, dass die das umstrukturieren, wäre aber auch nicht das Problem gewesen.

          Aber dass sie das Namensschema durch die Bank ändern, das war nicht angekündigt oder auch nur zu ahnen.

        • bleistift2 ( bleistift2@sopuli.xyz ) OPEnglish
          2·
          il y a 9 mois

          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);`
        • bleistift2 ( bleistift2@sopuli.xyz ) OPDeutsch
          2·
          il y a 9 mois

          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 @VegOwOtenks@lemmy.world:

          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.