🔥
MOe's Taverne Digital Workshop
Eingang
🔧 · Werkzeugkasten

Skripte & Tools: Klein, präzise, genau das was fehlt

Das perfekte Tool gibt es nie. Aber das Tool, das genau dein Problem löst, kann man in einer Stunde schreiben. Ich baue lieber fokussierte Skripte die eine Sache gut machen, als komplexe Systeme die alles können sollen.

Bash Python Node.js CLI Automation

Der Unterschied zwischen gutem und schlechtem Scripting

Ein schlechtes Skript macht viele Dinge halbherzig. Ein gutes Skript macht eine Sache zuverlässig – und macht sie so gut, dass man es nach einem Jahr noch versteht und vertraut.

Was ein gutes Skript ausmacht:

  • Vorhersagbares Verhalten: Gleicher Input, gleicher Output. Immer.
  • Sinnvolle Fehlermeldungen: Nicht „Error" – sondern was schiefgelaufen ist und warum.
  • Idempotenz: Mehrfaches Ausführen schadet nicht.
  • Minimale Abhängigkeiten: Kein Tool das 200 MB installiert, wenn awk reicht.

Ich halte mich an eine einfache Regel: Wenn ein Skript komplexer wird als nötig, ist es ein Signal, dass ich das Problem noch nicht verstanden habe. Zurück zu den Anforderungen, neu denken.

Bash, Python, Node.js: Wann welche Sprache?

Jede Sprache hat ihre Stärken. Ich wähle pragmatisch nach dem Einsatzzweck:

  • Bash: Server-Aufgaben, Datei-Operationen, Pipelines, Cron-Jobs. Wenn die Aufgabe aus dem Terminal kommen würde, ist Bash die erste Wahl. Bekannte Kandidaten: Backup-Skripte, Deploy-Helpers, Log-Rotation, System-Checks. Mein change_owner.sh-Skript für Dateiberechtigungen läuft täglich.
  • Python: Datenverarbeitung, API-Aufrufe, Textverarbeitung, Machine Learning. Wenn man Libraries braucht (requests, pandas, BeautifulSoup), ist Python die Wahl. Gut les- und testbar.
  • Node.js: Web-Tools, Webhooks, CLI-Tools mit interaktivem Interface. Wenn JSON und HTTP im Mittelpunkt stehen oder man npm-Packages nutzen will.

Für n8n-Workflows nutze ich den Code-Node, der JavaScript direkt ausführt – perfekt für kleine Transformationen innerhalb eines Workflows, die kein eigenes Skript rechtfertigen.

KI-gestützte Entwicklung: Prompts als Entwicklungshelfer

Seit ich lokale Sprachmodelle im Alltag nutze, hat sich mein Scripting-Workflow verändert. Nicht weil die KI das Skript schreibt – sondern weil sie den iterativen Prozess beschleunigt.

Wie ich es konkret einsetze:

  • Erstentwurf per Prompt: Ich beschreibe das Problem in natürlicher Sprache und lasse ein Modell (Codestral oder Llama 3.1) einen ersten Entwurf generieren. Das spart den leeren-Cursor-Moment.
  • Iteration per Kontext: Ich gebe das generierte Skript zurück und sage „macht X noch nicht richtig weil Y". Das Modell korrigiert gezielt.
  • Review per Prompt: „Erkläre mir dieses Skript Zeile für Zeile und nenne mögliche Probleme." Guter Sicherheitscheck vor produktivem Einsatz.

Gutes Prompt Engineering macht den Unterschied – wer sein Problem präzise formuliert, bekommt brauchbaren Code. Wer vage fragt, bekommt generischen Boilerplate.

# Guter Prompt für Code-Generierung "Schreibe ein Bash-Skript das: - alle .log-Dateien in /var/logs älter als 7 Tage löscht - vorher die Gesamtgröße berechnet und ausgibt - bei Fehler eine verständliche Meldung liefert - idempotent ist (mehrfaches Ausführen schadet nicht) Kommentiere kritische Stellen kurz."

Häufige Fragen zu Skripten & Tools

Am schnellsten durch echte Aufgaben. Nimm einen manuellen Prozess den du regelmäßig machst – Copy-Paste von Dateien, Log-Check, Backup – und automatisiere ihn. Wenn etwas nicht klappt, lass ein lokales Modell erklären was der Fehler bedeutet. Stack Overflow und ShellCheck für Syntax-Review.

In einem privaten Git-Repository. Versionskontrolle für Skripte ist kein Overkill – es ist die einfachste Versicherung gegen „vorher hat das noch funktioniert". Ich habe ein ~/scripts-Repo das auf jedem meiner Server via Git-Pull aktuell gehalten wird. Jedes Skript hat außerdem einen kurzen Kommentar-Header mit Zweck und Abhängigkeiten.

Skripte sind besser wenn: die Aufgabe einfach ist und keine GUI braucht, der Prozess über Cron läuft ohne externe Trigger, man maximale Portabilität braucht (kein laufendes n8n nötig), oder wenn die Komplexität eines n8n-Workflows für die Aufgabe übertrieben wäre. n8n ist besser wenn: mehrere Services verbunden werden, visuelle Übersicht wichtig ist, oder Nicht-Techniker den Workflow verstehen sollen.

Drei Stufen: 1. Trockenlauf (--dry-run implementieren oder alle destruktiven Befehle auskommentieren und nur echon). 2. Test auf einer Kopie der Daten. 3. Produktivtest mit einer kleinen Datenmenge. Für Bash: ShellCheck als statischen Analyzer nutzen, der findet viele klassische Fallstricke bevor das Skript läuft.