loki.dev

Brooks' Gesetz, jetzt mit Agenten

2026-08-06T09:00:00+00:00

Der Post wird jetzt wenig sinnstiftend, aber das Thema muss ich jetzt einfach loswerden: Folgendes Muster habe ich in mehreren Projekten gesehen, und es läuft immer gleich.

Monate vergehen, ohne dass jemand einen verbindlichen Termin setzt. Dann steht irgendwo ein Datum in einer Folie/Mail/Meeting, weil es nach außen zugesagt wurde, und plötzlich muss ein halbfertiger Stand in sechs Wochen fertig sein. In der Runde danach kommt aus dem C-Level der Vorschlag, den ich inzwischen erwarte:

... mehr Ressourcen.

Das Merkwürdige daran ist, dass der Vorschlag mit kürzerer Restlaufzeit sogar noch sicherer kommt. Bei sechs Monaten diskutiert man Umfang, bei sechs Wochen zwei zusätzliche Entwickler aus einem anderen Projekt. Fred Brooks hat 1975 aufgeschrieben, was dann passiert:

"Adding manpower to a late software project makes it later."

Das ist Brooks' Gesetz, aus The Mythical Man-Month. Brooks hatte damals das Material aus erster Hand: Er hat bei IBM die Entwicklung von OS/360 geleitet. Mit tausenden Beteiligten wurde jeder Termin gerissen. Sein erkanntes Problem ist die Einheit selbst. Kosten skalieren mit Personen mal Monaten, Fortschritt tut das aber explizit nicht.

Warum kurze Fristen es schlimmer machen

Die Einarbeitung frisst genau das Fenster, das noch da ist. Wer neu dazukommt, muss von den Leuten eingelernt werden, die bereits der Engpass sind. Bei sechs Wochen Restlaufzeit ist das die ganze Restlaufzeit.

Dazu kommt die Abstimmung. Bei n Personen gibt es n(n-1)/2 mögliche Kanäle, vier Leute haben sechs, acht Leute haben achtundzwanzig. Jeder davon ist eine Gelegenheit für zwei unterschiedliche Annahmen über dieselbe Schnittstelle, und die fallen erst in der Integrationswoche auf.

Teuer: Viel von der Arbeit ist sequenziell. Solange das Schema nicht migriert ist, kann niemand den Endpoint darauf umbauen. Ein zweiter Entwickler wartet dann genauso wie der erste, nur bezahlt.

Was geholfen hätte

Brooks' eigene Antwort ist unbequem und immer noch die einzige:

Umfang kürzen oder Termin verschieben.

In den Projekten, die doch noch gut ausgegangen sind, stand am Anfang eine ehrliche Liste, was zum Termin wirklich funktionieren muss. Der Rest kam ein Release später, und niemand außerhalb des Teams hat es gemerkt.

Und genau das wird immer als Option ausgeschlossen. Vielleicht sogar aus guten Gründen (meistens etwas wie "time2market beats quality" oder ähnliches), aber das ändert nichts daran, dass gewisse Dinge nicht mit der Realität vereinbar sind.

Und mit Agenten?

Seit ich mehrere Claude-Instanzen parallel laufen lasse, wird die Frage wieder gestellt, diesmal ohne Personalkosten. Eine der drei Ursachen fällt tatsächlich weg: Einarbeitung kostet fast nichts, der Kontext steht in AGENTS.md (oder CLAUDE.md oder GEMINI.md) und wird pro Agent wiederverwendet. Die Sequenz bleibt, der Abhängigkeitsgraph interessiert sich nicht dafür, wer davor sitzt. Und die Abstimmung kommt als Doppelarbeit zurück: zwei Agenten, die denselben Helper refaktorieren, jeder für sich plausibel.

Dazu ein Engpass, den Brooks nicht hatte. Ich bin der einzige, der Ergebnisse annehmen darf. Drei Agenten parallel bringen mir etwas, bei zehn lese ich nur noch Diffs und entscheide immer schlechter. Was mitskaliert, ist der deterministische Teil des Reviews: Linter, Typprüfung, Tests, Pre-Commit-Hooks urteilen bei zehn Agenten so schnell wie bei einem. Genau der Gedanke aus Teil 5 der Tooling-Serie (ja, das ist schamlose Eigenwerbung :D).

Nach 51 Jahren ist damit eine der drei Ursachen weggefallen und eine vierte dazugekommen. Für die Runde mit den sechs Wochen und dem Vorschlag von oben rechnet sich das genauso wie 1975.

(Der Großteil der Zahlen und Beispiele sind angepasste und basierend auf alten Erfahrungen und habe nichts mit aktuellen Ereignissen zu tun)

Moderne Werkzeuge Teil 5: Die Toolchain als Korsett für KI-Agenten

2026-07-26T12:00:00+00:00

In Teil 1 habe ich von zwei Umbrüchen geschrieben: das Python-Ökosystem wird auf Rust-basierte Werkzeuge umgestellt, und immer mehr Code entsteht durch KI. Die vier Teile davor haben den ersten Umbruch abgearbeitet. In diesem Bonus-Teil kommt der zweite dazu, denn beide passen besser zusammen, als es zunächst aussieht.

Kurz gesagt: Dieselben uv-, ruff-, ty- und prek-Checks, die mir die Arbeit erleichtern, sind auch das Korsett, das einen KI-Agenten produktiv und vertrauenswürdig(er) macht.

Warum ein Agent Leitplanken braucht

Ein KI-Agent schreibt in Sekunden plausibel aussehenden Code. Plausibel heißt aber nicht korrekt: Er erfindet APIs, übersieht None/null-Fälle, ignoriert die Architekturgrenzen des Projekts oder baut sich eben mal eine neue Abhängigkeit ein. Wer das alles per Hand reviewen will, hat den Geschwindigkeitsgewinn sofort wieder verloren.

Statt dem Agenten mehr zu vertrauen, gebe ich ihm eine Umgebung, in der Fehler sofort und deterministisch auffallen. Genau dafür habe ich die Toolchain ohnehin schon aufgebaut (und auch vor KI schon so genutzt).

Dieselben Checks, jetzt als Feedback-Loop für den Agenten

Für den Agenten brauche ich dafür kein neues Setup. Die Checks aus den Teilen 2 bis 4 sind schon eine maschinenlesbare, deterministische Wahrheit über den Code:

uv run ruff check --fix . räumt auf und meldet, was es nicht selbst fixen kann
uv run ty check fängt Typ- und None-Fehler ab, bevor sie Laufzeitfehler werden
uv run bandit und import-linter bewachen Sicherheit und Architektur
uv run pytest sagt, ob der Code überhaupt noch tut, was er soll

Der Agent bekommt diese Befehle an die Hand (bei mir in einer AGENTS.md bzw. CLAUDE.md/GEMINI.md mit Hinweis auf die AGENTS.md) und arbeitet in genau der Schleife, die ich als Mensch auch nutze: schreiben, prüfen, den Fehlern folgen, nachbessern, wiederholen. Der Unterschied ist nur, dass er die Schleife viel häufiger und schneller durchläuft.

Warum Geschwindigkeit zur Grundvoraussetzung wird

In den bisherigen Teilen war Geschwindigkeit "nur" Komfort. Beim Agenten wird sie zur Grundvoraussetzung. Ein Check, der 30 Sekunden dauert, killt eine Agenten-Schleife genauso wie meine eigene, nur dass der Agent vielleicht zwanzigmal pro Minute prüfen will. Erst weil ruff und ty im Millisekundenbereich antworten, kann der Agent eng iterieren, statt nach jedem Schritt minutenlang zu warten oder, schlimmer, die Checks ganz zu überspringen.

Das Korsett: Regeln, die der Agent nicht umgehen kann

Meine select = ["ALL"]-Strategie aus Teil 2, die strikte Typdisziplin aus Teil 3 und die Architekturregeln aus Teil 4 sind für einen Agenten wertvoller als für mich: Sie schreiben die Form des Projekts fest. Der Agent darf produktiv sein, aber nur innerhalb dieser Form.

Und es ist nicht verhandelbar: Der Pre-Commit-Hook blockt schlechten Code, bevor er in die Historie kommt, und die CI fängt den Rest (auch das --no-verify eines übermotivierten Agenten). Der Agent kann noch so überzeugt argumentieren, der rote Check bleibt rot.

Fazit

Dass die beiden Umbrüche aus Teil 1 zeitgleich passieren, ist kein Zufall. Eine schnelle, strikte, deterministische Toolchain ist die Voraussetzung dafür, dass KI-gestützte Entwicklung nicht in einem Berg plausibler, aber kaputter Diffs endet. Die Werkzeuge, die mir die Arbeit erleichtern, sind dieselben, die einen Agenten in der Spur halten.

Die Serie:

Teil 1: uv
Teil 2: ruff
Teil 3: ty
Teil 4: prek
Teil 5: Korsett für KI-Agenten (Bonus, dieser Teil)

Moderne Werkzeuge Teil 4: Hochperformante Git Hooks mit prek

2026-07-20T21:00:00+00:00

Im Laufe dieser Serie habe ich meinen Python-Stack mit uv (Teil 1), ruff (Teil 2) und ty (Teil 3) neu aufgebaut. In Teil 4 bringe ich dann alles zusammen: Die Checks sollen automatisch laufen, bevor Code überhaupt ins Repository gelangt. Kein Mensch hat Bock, ständig diesen Stack an Tools von Hand auszuführen.

Git Hooks als Quality Gate

Jeder Check, der erst in der CI scheitert, ist eine Verzögerung und reißt mich aus meinen Tasks raus: schreiben, committen, pushen, fünf Minuten warten, rote Pipeline, fixen, "Fix linting"-Commit, nochmal pushen. Ein Pre-Commit-Hook verschiebt genau dieselben Checks an den frühestmöglichen Punkt: Fehler werden behoben, bevor sie in der Historie landen, und die CI wird vom Fehlerfinder zum reinen Sicherheitsnetz.

Der Engpass beim klassischen pre-commit

Das pre-commit-Framework ist seit Jahren ein Standard dafür. Auch Tools wie lefthook oder husky sind super. prek ist aber flott und dank Kompatibilität zu pre-commit mein Tool der Wahl. Denn pre-commit hat einige Nachteile: Es ist selbst ein Python-Paket, isoliert jeden Hook in einer eigenen virtuellen Umgebung und führt Hooks sequenziell aus. Das erste git commit nach einem frischen Clone kann Minuten dauern, während Umgebungen aufgebaut werden.

prek

prek ist eine Reimplementierung des pre-commit-Frameworks in Rust, und der entscheidende Punkt ist: Es liest dieselbe .pre-commit-config.yaml. Aber mit smarterem Caching und ohne den Virtualenv-Overhead:

# Installation (ein statisches Binary, kein Python nötig)
uv tool install prek
# alternativ mit brew/pacman/apt/etc.

# Git-Hook im Repository aktivieren (einmalig pro Clone)
prek install

# Hooks manuell ausführen
prek run                # gegen gestagte Dateien
prek run --all-files    # gegen die gesamte Codebasis
prek run gitleaks --all-files  # einen einzelnen Hook gezielt

Mein Hook-Setup im Detail

Die .pre-commit-config.yaml meines Templates verkettet alles, was ich in den letzten drei Teilen aufgebaut habe. Interessant ist dabei die Unterscheidung zwischen zwei Hook-Arten:

Remote-Hooks kommen aus fremden Repositories: die Basics wie YAML/TOML-Validierung, Trailing Whitespace und der Secret-Scanner gitleaks:

- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v6.0.0
  hooks:
  - id: check-yaml
  - id: check-toml
  - id: check-merge-conflict
  - id: trailing-whitespace
  - id: end-of-file-fixer

- repo: https://github.com/gitleaks/gitleaks
  rev: v8.30.1
  hooks:
  - id: gitleaks

Lokale Hooks dagegen laufen über uv run in meiner Projektumgebung: damit prüfen ruff, ty und bandit exakt in den Versionen, die in der uv.lock gepinnt sind, statt in irgendeiner separaten Hook-Umgebung:

- repo: local
  hooks:
  - id: ruff-format
    name: ruff format
    entry: uv run ruff format
    language: system
    types: [python]

  - id: ruff-check
    name: ruff check
    entry: uv run ruff check --fix
    language: system
    types: [python]

  - id: ty
    name: ty-check
    entry: uv run ty check --verbose --output-format=full .
    language: system
    types: [python]
    pass_filenames: false

  - id: bandit
    name: bandit
    entry: uv run bandit -r src/app -c pyproject.toml
    language: system
    types: [python]
    pass_filenames: false

Dazu kommt noch import-linter, der meine Architektur bewacht: Er schlägt fehl, sobald jemand aus der Domain-Schicht heraus Infrastruktur importiert: Architekturregeln als ausführbarer Check statt als Wiki-Seite.

Ein Commit, das ganze Quality Gate

Bei jedem git commit läuft damit automatisch: Formatting, Linting mit Auto-Fix, Type Checking, Security-Scan (bandit), Secret-Scan (gitleaks) und die Architekturprüfung. Dank prek weitgehend parallel und in wenigen Sekunden, schnell genug, dass niemand in Versuchung kommt, es abzuschalten.

Für den Notfall gibt es trotzdem die Hintertür:

git commit --no-verify

Aber genau dafür (naja, oder für die Fälle, wo jemand prek install vergessen hat) ist die CI das Sicherheitsnetz: Dort laufen dieselben Checks (ruff format --check, ruff check, ty check, bandit, lint-imports, pytest) noch einmal, nur eben als letzte Instanz, nicht als erste.

Fazit der Serie

Diese vier Tools uv, ruff, ty und prek ersetzen jeweils einen langsamen, fragmentierten Teil der Python-Toolchain durch ein schnelles Rust-Binary, und bleiben dabei kompatibel zu dem, was sie ablösen (pyproject.toml, Black-Formatierung, .pre-commit-config.yaml).

Und wenn ich ehrlich bin, sind sie meist die ersten Tools ihrer Art, denn eine Codebasis, die hier schon perfekt war, habe ich bisher nicht gesehen.

Die Serie:

Moderne Werkzeuge Teil 3: Die Zukunft des Type Checkings mit ty

2026-07-20T07:32:00+00:00

Bisher habe ich in dieser Serie das Paketmanagement mit uv (Teil 1) und das Linting mit ruff (Teil 2) optimiert. In Teil 3 kommt der anspruchsvollste Teil der statischen Analyse: das Type Checking.

Warum Type Checking?

So richtig in Kontakt mit Typechecking bin ich damals über phpstan/psalm in PHP gekommen. Das fühlte sich an, als käme die Validierung, die ich aus anderen Sprachen kannte, endlich auch in den Scriptsprachen an. JA: Es ist etwas mehr Arbeit, und natürlich sind Arrays (PHP) bzw. Listen nicht mehr ganz so flexibel. Einfach alles reinschmeißen ist aber ohnehin keine gute Idee. Für mich haben Typechecker also sinnvolles Verhalten erzwungen, statt zufällig Regeln anzuwenden, die mir das Leben schwer machen.

Der Hauptgrund für mich ist aber, dass Typechecker in Scriptsprachen einfach komplette Kategorien an Fehlern auslöschen. In Kombination mit Lintern sollte man in Python extrem viel weniger (oder sogar gar keine) None-Fehler mehr haben. Bei konsequentem Einsatz umgeht man viele Probleme, z. B. nicht abgefangene logische Branches in match/if-elif-else-Kaskaden.

Und schließlich: Code Completion. Mit KI ist das natürlich weniger wichtig, aber jede moderne IDE kann diese Typehints auswerten und damit sinnvolle Vorschläge machen. Der Erfolg von FastAPI/pydantic beruht zum Teil genau darauf, dass die DX (Developer Experience) so gut ist!

In meinem Template mit hexagonaler Architektur sind Typen sogar tragend: die Ports sind als abstrakte, vollständig typisierte Interfaces definiert:

class ItemRepository(ABC):
    @abstractmethod
    async def save(self, item: Item) -> Item: ...

    @abstractmethod
    async def by_id(self, item_id: UUID) -> Item | None: ...

Ein Type Checker stellt sicher, dass jeder Adapter diesen Vertrag exakt erfüllt, und dass niemand vergisst, den None-Fall von by_id zu behandeln.

Das Problem war nie der Nutzen, sondern der Preis: mypy wird auf wachsenden Codebasen spürbar langsam. Und ein Check, der 30 Sekunden dauert, wird lokal nicht mehr ausgeführt, er wandert in die CI, und Typfehler fallen erst nach dem Push auf. Genau das Feedback-Loop-Problem, das ruff fürs Linting gelöst hat, existierte beim Type Checking weiter.

ty

ty ist Astrals Antwort darauf: ein in Rust geschriebener, auf massive Parallelität ausgelegter Type Checker, der sich direkt in die uv/ruff-Toolchain einfügt. Der Check läuft so schnell, dass er problemlos in jeden Pre-Commit-Hook passt:

uv run ty check

Ein typischer Fund sieht dann so aus: hier vergisst jemand, dass by_id auch None liefern kann:

item = await repository.by_id(item_id)
print(item.name)  # error: `name` on `Item | None`, `None` hat kein `name`

Zur Laufzeit wäre das ein AttributeError in Produktion. Mit ty ist es eine rote Zeile, bevor der Commit überhaupt entsteht, je nach CI-Tooling sogar ein verhinderter Commit oder Merge.

Meine Typdisziplin

Wichtig zur Einordnung: Dass jede Funktion, Variable und Klasse vollständig typisiert sein muss und Any die absolute Ausnahme bleibt, ist keine Eigenschaft von ty, sondern eine Projektregel meines Templates. ty ist das Werkzeug, das sie durchsetzbar macht, gemeinsam mit den ANN-Regeln von ruff, die fehlende Annotationen anmahnen.

Im Pre-Commit-Hook läuft der Check über die gesamte Codebasis:

- id: ty
  name: ty-check
  entry: uv run ty check --verbose --output-format=full .
  language: system
  types: [python]
  pass_filenames: false

pass_filenames: false ist hier bewusst gesetzt: Type Checking ergibt nur über das ganze Projekt Sinn, denn eine Änderung in Datei A kann einen Typfehler in Datei B auslösen. Dank der Geschwindigkeit von ty kann ich mir den Voll-Check bei jedem Commit leisten. Nice :).

Im Editor

ty ist nicht nur ein CLI-Tool, sondern bringt einen eigenen Language Server mit: Autocompletion, Hover, Go-to-Definition und Auto-Imports, alles in ty-Geschwindigkeit.

VS Code: Es gibt eine offizielle ty-Extension von Astral. Sie schaltet den Language Server der Python-Extension automatisch ab (setzt python.languageServer auf None), damit nicht zwei Language Server gleichzeitig laufen.

PyCharm: Ab Version 2025.3 ist ty direkt eingebaut. Unter Settings → Python | Tools → ty die Checkbox Enable setzen. PyCharm findet die im Interpreter installierte ty-Version dann selbst.

Darunter steckt immer derselbe Language Server, den man auch manuell starten kann (uv run ty server), z. B. für Neovim.

Einschränkungen

ty ist jung. Mein Template pinnt es auf ty==0.*: die Null vor dem Punkt ist im Open-Source-Umfeld nicht immer aussagekräftig. Hier stimmt sie aber durchaus, ty ist bis Version 0.0.61 offiziell noch eine Beta. Meiner Meinung nach (sehr subjektiv!) ist es aber bereits production ready, der Speed-Vorteil ist es mir einfach wert.

In meinen Architecture Decision Records markiere ich die Einführung trotzdem als Experimental: Ich evaluiere ty als primären Type Checker und beobachte, wie schnell es bei komplexeren Typing-PEPs (Generics, ParamSpec, Overloads) zu mypy/pyright aufschließt.

Für ein Template und Greenfield-Projekte ist das Risiko überschaubar, die Typkonstrukte sind dort selten exotisch. Wer eine große Bestands-Codebasis mit ausgefeilten mypy-Plugin-Setups hat, sollte den Wechsel dagegen bewusst abwägen: mypy ist bei der Regelabdeckung aktuell noch ausgefeilter.

Fazit

Der eigentliche Gewinn von ty ist nicht die bessere Analyse, sondern ein Type Checker, der flott läuft: lokal, bei jedem Commit, ohne dass man warten muss. Typdisziplin hält man nur durch, wenn das Feedback schnell kommt, und genau das liefert ty.

Die Serie:

Moderne Werkzeuge Teil 2: Einheitliches Linting und Formatting mit ruff

2026-07-16T17:14:00+00:00

Nachdem ich in Teil 1 das Paketmanagement mit uv aufgeräumt habe, will ich mich heute in Teil 2 um ruff kümmern.

Toolchain-Suppe

"Code-Qualität" hieß lange, vier bis fünf Tools hintereinander zu schalten:

Black für das Formatting
Isort für die Import-Sortierung
Flake8 (oder pylint) für das Linting (plus ein Dutzend Plugins)
pyupgrade für moderne Syntax
und Bandit für Sicherheitschecks

Auch hier galt: Jedes Tool hat seine eigene Konfigurationsdatei, eine eigene Version und eigene Konflikte mit: Black und Isort mussten z. B. explizit aufeinander abgestimmt werden, damit sie sich nicht gegenseitig die Imports umformatierten.

Und es war langsam. Auf mittleren Codebasen liefen diese Checks sekunden- bzw. teilweise sogar minutenlang. Imho zu langsam, um sie bei jedem Speichern oder Commit auszuführen. Ich hatte sie trotzdem immer aktiv, war dann meist schon beim nächsten Problem und wurde prompt wieder rausgeworfen, weil es irgendein Trivialproblem gab. Also mehr als einmal deaktiviert und am Ende vergessen, sie nochmal auszuführen, nur um dann von einer roten CI-Pipeline genervt zu werden.

ruff!

ruff ist Linter und Formatter in einem Rust-Binary. Es implementiert die Regeln von Flake8 (inklusive der populären Plugins), Isort, pyupgrade und großen Teilen von Bandit, und formatiert Black-kompatibel (mit minimalen Abweichungen). Die Laufzeit liegt selbst auf großen Codebasen im Millisekundenbereich, was einen entscheidenden Unterschied macht:

Checks, die instant sind, laufen bei jedem Speichern im Editor, bei jedem Commit und in der CI. Checks, die Sekunden dauern, laufen irgendwann nur noch in der CI. Zusammen mit --fix einfach geniales Tooling, das auch unabhängig von der IDE funktioniert <3.

Die beiden Befehle, die du brauchst:

# Linting-Fehler finden und automatisch beheben, wo möglich
uv run ruff check --fix .

# Die Codebasis formatieren
uv run ruff format .

In der CI drehe ich den Spieß um, dort wird nichts repariert, sondern nur geprüft:

- name: Formatting Check (Ruff)
  run: uv run ruff format --check .

- name: Linting Check (Ruff)
  run: uv run ruff check .

Meine Konfiguration: Opt-out statt Opt-in

Die meisten Projekte aktivieren eine Handvoll Regelgruppen und ergänzen nach und nach. Mein Template geht den umgekehrten Weg: alle Regeln an, und jede Ausnahme muss begründet werden. Das zwingt dazu, sich bei jedem ignore bewusst zu entscheiden, und dokumentiert die Entscheidung gleich mit:

# Teil der pyproject.toml
[tool.ruff.lint]
# Ich will strikt sein und nur bewusst abwählen!
select = [ "ALL" ]
fixable = [ "ALL" ]

ignore = [
  # strict
  "D102",    # würde Docstrings für jede öffentliche Methode erzwingen
  "D203",    # inkompatibel zu D211 (kein Leerzeile vor Klassen-Docstring)
  "EM101",   # würde erzwingen, Exception-Texte erst in Variablen zu speichern

  # inkompatibel mit "ruff format"
  "COM812",

  # temporär - als Beispiel
  "TC003",   # würde TYPE_CHECKING-Blöcke erzwingen.
]

Der Kommentar hinter jeder Regel ist kein Nice-to-have, sondern der Kern der Strategie: In einem Jahr weiß niemand mehr, warum COM812 aus ist, außer es steht daneben.

Per-File-Ignores: Tests sind anders

Regeln, die im Produktivcode sinnvoll sind, sind in Tests oft Lärm. assert ist in Tests der Normalfall (im Produktivcode verbietet ihn die Bandit-Regel S101), und "Magic Numbers" in einem Testfall sind schlicht die Testdaten:

# Teil der pyproject.toml
[tool.ruff.lint.per-file-ignores]
"tests/*" = [
    "ANN201",   # Rückgabe-Annotationen für Testfunktionen: unnötig
    "PLR2004",  # Magic Values in Vergleichen: das SIND die Testdaten
    "S101",     # assert ist in pytest essentiell
]

Import-Sortierung inklusive

Isort ist als Regelgruppe I gleich mit an Bord. Damit die Sortierung auch in Grenzfällen deterministisch bleibt, deklariere ich explizit, was third-party und was mein eigener Code ist:

[tool.ruff.lint.isort]
known-third-party = ["fastapi", "pydantic", "starlette"]
known-local-folder = ["app"]

Kurze Erinnerung: isort sorgt dafür, dass die Importblöcke grob in 3 Kategorien unterteilt sind:

"batteries included" Imports, z. B.: from math import sqrt
3rd party Imports: from fastapi import FastAPI
Projektimports: from my_project.domain import ImportantClass

Innerhalb der Blöcke dann alphabetisch.

Im Editor: Feedback beim Tippen

Der eigentliche Gewinn kommt, wenn ruff schon beim Tippen läuft und nicht erst beim Commit.

VS Code: Die offizielle Ruff-Extension (von charliermarsh/Astral) übernimmt Linting und Formatting. Wichtig ist mir, dass sie die im Projekt gepinnte Version nutzt: ruff.importStrategy steht per Default auf fromEnvironment, greift also auf das ruff aus der uv-Umgebung zu statt auf die mitgelieferte Version.

// .vscode/settings.json
{
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  },
  "ruff.importStrategy": "fromEnvironment"
}

Das .ruff-Suffix an den Code-Actions sorgt dafür, dass wirklich ruff fixt und die Imports sortiert und nicht versehentlich ein anderer Formatter.

PyCharm: Ab Version 2025.3 ist die Ruff-Unterstützung eingebaut. Unter Settings → Tools → Ruff aktivieren, dann greifen Reformat Code und Optimize Imports auf ruff zu. Für ältere Versionen gibt es das Ruff-Plugin von koxudaxi. In beiden Fällen lohnt es sich, auf das ruff aus der Projektumgebung zu zeigen statt auf eine global installierte Version.

Fazit

ruff ersetzt vier Konfigurationsdateien durch einen Block in der pyproject.toml und macht Linting so schnell, dass es keine Ausrede mehr gibt, es nicht überall laufen zu lassen. Die Opt-out-Strategie mit select = ["ALL"] ist dabei bewusst radikal: Sie kostet beim Aufsetzen etwas Zeit, liefert dafür aber ein Regelwerk, in dem jede Ausnahme ein dokumentierter Entschluss ist statt ein historischer Zufall.

Die Serie:

Moderne Werkzeuge Teil 1: Blitzschnelles Package Management mit uv

2026-07-13T19:50:00+00:00

Hey und willkommen zu meiner Serie über moderne Python-Werkzeuge: vier Teile über die Werkzeuge selbst, dazu ein Bonusteil über KI-Agenten. Ich schreibe das gerade, weil das Python-Ökosystem einen echten Umbruch erlebt. Genau genommen sogar mehrere:

Das Python-Ökosystem wird zu großen Teilen durch Rust-basierte Werkzeuge ersetzt. Das habe ich zu großen Teilen Astral zu verdanken.
Immer größere Teile der Entwicklung werden von KI diverser Hersteller erledigt, und die Kontrolle selbiger führt zu wachsenden Problemen.

Praktischerweise passen diese beiden Umbrüche perfekt zusammen.

Mein Ziel ist also, erst diese neuen Rust-basierten Werkzeuge vorzustellen und dann zu zeigen, wie sie in der KI-getriebenen Entwicklung helfen können. Ich schaue mir vier+ dieser Werkzeuge an, und zwar nicht abstrakt, sondern anhand eines realen FastAPI-Projekt-Templates: uv, ruff, ty und prek (+weitere Mini-Tools).

In Teil 1 (dieser hier) geht es um das Fundament: uv.

Das Problem, dass ich sehe: fünf Tools für eine Aufgabe

Wer bisher ein Python-Projekt sauber aufsetzen wollte, brauchte einen ganzen Werkzeugkasten:

pyenv, um die richtige Python-Version zu installieren
venv oder virtualenv (pipenv habe ich auch schon genutzt), um eine isolierte Umgebung zu erzeugen
pip, um Pakete zu installieren
pip-tools, pip freeze (oder poetry), um Abhängigkeiten zu locken
dazu das source .venv/bin/activate-Ritual (gerne auch automatisiert via zsh/bash script)

Jedes dieser Tools hat eine eigene Konfiguration (inklusive eigene Konfigurationstypen), eigene Eigenheiten und eigene Fehlerquellen. Das Ergebnis ist: "Works on my machine". Gratis dazu: eine CI-Pipeline, die Minuten mit dem Auflösen von Abhängigkeiten verbringt.

Die Lösung: uv, ein einzelnes Binary

uv ersetzt den kompletten Stack durch ein einziges Rust-Binary. Es ist Paket-Installer, Environment-Manager, Dependency-Resolver und Python-Versions-Manager in einem. Das Beste: es ist dabei um Größenordnungen schneller.

Installation geht flott:

curl -LsSf https://astral.sh/uv/install.sh | sh
# oder auf macOS:
brew install uv

(Wie immer gilt: install script erst lesen oder sogar erst runterladen und dann ausführen. Hier ist der Einfachheit halber nur der direkte Schritt aus der Doku vermerkt)

Workflow

Danach reduziert sich der Python-Alltag auf drei Befehle:

# Abhängigkeiten aus dem Lockfile installieren (inkl. venv-Erstellung)
uv sync

# Ein Paket hinzufügen: aktualisiert pyproject.toml UND uv.lock
uv add fastapi

# Beliebigen Befehl in der Projektumgebung ausführen
uv run pytest

Es gibt also kein activate mehr. uv run sorgt selbst dafür, dass der Befehl in der richtigen Umgebung läuft und dass diese Umgebung mit dem Lockfile übereinstimmt. Ist sie es nicht, synchronisiert uv sie vorher automatisch. Via uv venv (optional mit --python 314) kann man auch getrennt eine venv Umgebung erstellen. Alternativ kann man im Projekt eine .python-version Datei mit dem Inhalt 3.14 anlegen. Dann lädt uv den passenden Interpreter bei Bedarf einfach herunter. pyenv wird damit überflüssig.

Dependency Groups statt requirements-Wildwuchs

Statt requirements.txt, requirements-dev.txt und requirements-test.txt definiert mein Template alles in der pyproject.toml, mit dem Standard für Dependency Groups (PEP 735), inklusive Gruppen, die andere Gruppen einbinden:

[dependency-groups]
dev = [
  "prek==0.4.9",
  { include-group = "tests" },
  { include-group = "lint" },
]

tests = [
  "httpx==0.*",
  "pytest==9.*",
  "pytest-asyncio",
]

lint = [
  "ruff==0.*",
  "ty==0.*",
  "bandit==1.*",
  "import-linter>=2.11",
]

uv sync installiert standardmäßig die dev-Gruppe, uv sync --no-dev lässt sie weg. Perfekt für die Production Environment. Weitere Flags für die Gruppen sind --all-groups bzw. sehr spezifisch --group lint|tests|dev.

Reproduzierbarkeit: uv.lock

Wichtig für stabile Deployments ist die uv.lock: Sie hält jede Abhängigkeit (inklusive Subabhängigkeiten) mit exakter Version und Hash fest, plattformübergreifend. In CI und Docker erzwinge ich mit --frozen, dass das Lockfile aktuell ist. Weicht die pyproject.toml davon ab, schlägt der Build fehl, statt still etwas anderes zu installieren.

So sieht das in einem beispielhaften Dockerfile meines Templates aus (Multi-Stage, mit Cache-Mount):

# Bewusst kein alpine, da das gerade mit binary builds (z. B. psycopg2/etc.)
# schonmal Mehrarbeit ist.
FROM python:3.14-slim AS builder

ENV UV_COMPILE_BYTECODE=1
ENV UV_LINK_MODE=copy

# Erster Schritt: uv haben. Es gibt aber auch fertige Docker Images!
COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv
COPY pyproject.toml uv.lock ./

# Erst nur Dependencies, dieser Layer wird gecached,
# solange sich das Lockfile nicht ändert
RUN uv sync --frozen --no-dev --no-install-project

# Dann der sourcecode -> häufige änderungen
COPY src ./src

# Install mithilfe von cache (macht gerade bei CI einen gigantischen Unterschied)
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --frozen --no-dev

Und in der GitHub-Actions-Pipeline übernimmt die offizielle Action Setup und Caching in einem Schritt:

- name: Install uv
  uses: astral-sh/setup-uv@v8.2.0
  with:
    python-version: "3.14"
    enable-cache: true

- name: Install dependencies
  run: uv sync --all-groups

Fazit

uv braucht weniger Konfiguration als der alte Stack und ist trotzdem deutlich schneller. Es ist der Grund, warum alle folgenden Teile dieser Serie mit uv run ... beginnen. Damit werden Python-Entwicklung, CI, CD u. v. m. schneller.

Bonusfeature: Scripts mit Inline-Dependencies laufen lassen. Perfekt für DevOps und Ähnliches. :)

Die Serie:

Claude Code, Claw Code und das Ende der Geheimnisse?

2026-05-04T12:00:00+00:00

Sorry für die lange Funkstille! Seit dem letzten Post ist ja doch einiges an Zeit ins Land gegangen. Ich hab hier noch einen ganzen Stapel an Entwürfen rumliegen (.md.draft), aber wenn ich mir die so anschaue, müssen die wohl alle erst mal grundlegend überarbeitet werden, die Welt (und vor allem die KI-Welt) dreht sich einfach zu schnell ;).

Aber jetzt treibt mich gerade genau diese KI rum und mir fehlt eine Stimme, die weder komplett vom Hype überrannt, noch in ihrem Loch lebt und die aktuelle Entwicklung ignoriert. Daher mache ich das jetzt einfach mal - sogar frei von KI geschrieben.

Claude Code direkt als erstes, da es ziemlich deutlich die Beliebtheitsskala bei Entwicklern anführt. Es ist schon faszinierend (und ein bisschen ironisch), dass ausgerechnet ein Tool, das uns beim Programmieren helfen soll, seinen eigenen Quellcode veröffentlicht - und das sogar nachdem Mythic (das Ding, was so gut ist, dass man es vor der Öffentlichkeit verstecken muss) bereits im Einsatz war; oder weil? 🤔 Manche erinnern sich vielleicht noch an GPT5 wo ähnliches behaupted wurde.

Claw Code

Wer sich das Ganze mal im Detail anschauen will (solange es noch online ist), sollte einen Blick auf Claw Code werfen. Das Projekt hat den geleakten Code quasi "deductiv" aufbereitet und zugänglich gemacht. Es ist ein extrem spannendes Stück Softwarearchitektur, das zeigt, wie Anthropic die Interaktion zwischen LLM und lokaler Shell orchestriert.

Die rechtliche Seite: DMCA-Whack-A-Mole

Natürlich findet Anthropic das Ganze weniger witzig. Es gab wohl schon über 8100 Löschanfragen. Heise hat dazu einen sehr guten Artikel geschrieben, der die rechtlichen Aspekte beleuchtet. Es ist die klassische "Geburtsstunde" eines Tools aus einem Leak heraus, und der verzweifelte Versuch, die Katze wieder in den Sack zu kriegen.

Ich finde das ziemlich bezeichnend für den current State der KI:

Die Tools werden immer mächtiger, aber auch komplexer.
Der Code (und die Bugs) entstehen schneller und kriegen immer weniger echte Reviews
"Security by Obscurity" funktioniert mit KI noch weniger als vorher

Gerade überlege ich noch, ob ich dazu mal einen tieferen Artikel schreibe, wo ich mich speziell um KI Guardrails, also eine Art Sicherheitskorsett für KI kümmere. Ich habe das Gefühl, dass dies vielen noch fehlt obwohl es echt eine schöne tief hängende Frucht ist.

Immutability / Const vs Let

2024-12-06T09:34:00+00:00

tl;dr

const bevorzugen statt let
Variablen so oft wie möglich unveränderlich halten

Ich erkläre hier, warum Immutability so nützlich ist und wie man sie in TypeScript einsetzt, ähnliche Konzepte gelten aber auch in anderen Sprachen.

Was ist Immutability?

Der Name beschreibt es eigentlich schon: Dinge unveränderlich machen. In TypeScript sind alle primitiven Datentypen bereits unveränderlich!

Beispiel:

let a = 5;
let b = a;
a = 123;
// 5 existiert noch im Speicher

b = 42;
// 5 wird bald garbage collected

Kleiner Hinweis für zukünftige Inhalte: Immutability ist ein zentrales Konzept in der funktionalen Programmierung ;).

Tiefer einsteigen mit einem Beispiel:

let helloWorldString = "Hello World!"; // unveränderlich
helloWorldString = "Hello Moon!"; // kein Fehler, aber der Variablenname stimmt nicht mehr!

// vs:

const helloWorldString = "Hello World!"; // unveränderlich
helloWorldString = "Hello Moon!"; // Fehler! Wir können uns auf den Inhalt verlassen!

Im oberen Beispiel ändert sich der Inhalt der Variable und es wird schwerer vorherzusagen, was drin steckt.

„Aber was ist mit Zählervariablen? Ich muss doch ständig zählen!"

Richtig. Aufgedröselt:

Die Faustregel lautet:

veränderliche Variablen möglichst vermeiden
wenn veränderliche Variablen die Lesbarkeit verbessern oder die einzige sinnvolle Option sind (sehr selten): dann verwenden

Mit „selten" meine ich, dass TypeScript/JavaScript uns in vielen Fällen einen Weg bietet, Zählervariablen zu vermeiden:

let uppercaseNames = [];
for (let name of ["alice", "bob", "charlie"]) {
  uppercaseNames.push(name.toUpperCase());
}

// Funktionaler Ansatz
const uppercaseNames = ["alice", "bob", "charlie"].map((name) =>
  name.toUpperCase(),
);

Dieses Beispiel ist trivial, aber in jedem Fall: Wir WISSEN, dass uppercaseNames genau das enthält, was es sagt, sobald es definiert ist!

Warum

Immutability bedeutet nicht, alles konsequent durchzuziehen, und veränderliche Variablen sind auch nicht per se schlecht, aber sie eliminieren einige Fehlerquellen beim Programmieren und Debuggen.

Biome hat einen Lint lint/style/useConst, der zwingt, const zu verwenden, wenn eine Variable nie neu zugewiesen wird. Ich würde aber noch einen Schritt weiter gehen und let so oft wie möglich durch const ersetzen.

Folgendes Szenario:

const mutateVar = (innerA) => {
  innerA = 9;
  return 12;
};

let outerA = 123;
const result = mutateVar(outerA);
// keine Änderung, da elementare Typen per Wert übergeben werden
console.log({ result, outerA });

// Aber:
const mutateObj = (obj) => {
  // Seiteneffekt, den wir beim Lesen des Funktionsnamens nicht erwarten:
  obj.x = 123;
  return obj;
};

const originalObject = { a: 42 };
const mutatedObject = mutateObj(originalObject);
console.log({ originalObject, mutatedObject });

Wir erwarten, dass originalObject noch gleich ist und mutatedObject den neuen Wert enthält. Wenn wir uns angewöhnen, bestehende Objekte nicht zu verändern und const zu verwenden, werden wir nie von Verhalten innerhalb einer Funktion überrascht.

Funktionen, die Parameter nicht mutieren und ausschließlich von ihren Parametern abhängen, heißen pure functions. Ein Konzept mit vielen Vorteilen gegenüber unreinen Funktionen, dazu mehr im nächsten Artikel.

Aber const-Objekte sind doch NICHT unveränderlich

Stimmt. Besonders wegen JavaScript. Glücklicherweise haben wir in TypeScript mächtige Werkzeuge: Readonly, readonly und as const.

// Readonly
type Tree = { name: string };
const ahorn: Readonly<Tree> = { name: "ahorn" };
ahorn.name = "bhorn"; // TypeScript-Fehler

// As const
const ahorn = { name: "ahorn" } as const;
ahorn.name = "bhorn"; // TypeScript-Fehler

// readonly
class Tree {
  constructor(readonly name: string) {}
}

const t = new Tree("ahorn");
t.name = "asdf"; // TypeScript-Fehler

Was ist mit String-Buildern?

Ich bevorzuge persönlich:

Den Aufbau eines Strings in eine Funktion auszulagern
Ein Template am Ende zu haben, in das die verschiedenen Teile einfließen

/** Ansatz der meisten Leute */
function greetCustomer(customer) {
  let message = "";
  if (customer.age > 15) {
    message += "Guten Tag,\n";
  } else {
    message += "Hey,\n";
  }

  if (customer.hasEaten) {
    message += "Darf ich Ihnen etwas zu trinken anbieten?";
  } else {
    message += "Darf ich Ihnen unsere Mittagskarte zeigen?";
  }

  console.log(message);
}

// vs. mein Ansatz
function buildGreeting(customer): string {
  const greet = customer.age > 15 ? "Guten Tag" : "Hey";
  const offer = customer.hasEaten ? "etwas zu trinken" : "unsere Mittagskarte";
  return `${greet},\nDarf ich Ihnen ${offer} anbieten?`;
}

function greetCustomer(customer) {
  const greeting = buildGreeting(customer);
  console.log(greeting);
}

Das ist besser, weil es:

die Komplexität reduziert und die Struktur des Endtextes klarer macht
die Einrückungstiefe verringert, auch ein Thema für einen eigenen Artikel!
die Logik in eine pure function auslagert, während die Funktion mit Seiteneffekten nur diese nutzt
buildGreeting damit einfacher testbar macht, da wir nicht auf Console-Output angewiesen sind

Linter & Stylecheck

2024-12-02T09:00:00+00:00

Stylecheck

Fangen wir mit dem einfacheren Thema an: Stylechecks. Im Kern geht es darum, den gleichen Stil über die gesamte Anwendung beizubehalten. Welcher Stil das ist, ist dabei gar nicht so wichtig: Hauptsache, er ist überall gleich!

Warum?

Pattern-Matching: Unabhängig vom Erfahrungsstand ist es einfacher, Muster zu erkennen, wenn sie immer gleich aufgebaut sind.
Git-Diffs: Unterschiedliche Stile führen zu einem ständigen Hin-und-Her in den Diffs, wenn verschiedene Styles aufeinandertreffen.
Werkzeuge: Ein Tool, das Code automatisch formatiert und Regeln direkt anwendet, spart enorm viel Zeit!

Tools

prettier ist das bekanntere Werkzeug dafür
Ich bevorzuge aber biome, da es schneller ist und auch Linting übernehmen kann
- Es ist zu 97 % kompatibel mit Prettier (gleiche Regeln), die Unterschiede sind nachvollziehbar
- Es kann formatieren: JavaScript, TypeScript, JSX, TSX, JSON, CSS und GraphQL

Beispiele

Trivial: einheitliche Anführungszeichen ' vs " oder konsistente Einrückung
Lesbarkeit: Lange Import-Zeilen auf mehrere Zeilen aufteilen

Trivial: Leerzeichen

// VORHER
@Injectable()
export class JwtService {
    
    decodeToken (token: string): any {
        return jwt.decode(token);
    }
}

// NACHHER
@Injectable()
export class JwtService {
    decodeToken(token: string): any {
        return jwt.decode(token);
    }
}

oder Tabs vs. Spaces:

// VORHER: 2 Spaces
describe('ReportsController', () => {
  let controller: ReportsController;

  beforeEach(async () => {

// NACHHER: Tabs
describe('ReportsController', () => {
	let controller: ReportsController;

	beforeEach(async () => {

* Ich persönlich bevorzuge Spaces, aber Konvention über Sympathie!

Trivial: Zeilenumbrüche

// VORHER
@Module({
  controllers: [IntegrationController],
  providers: [IntegrationService, PrismaService, ScrapingService, CustomerIoService, JwtService]
})

// NACHHER
@Module({
	controllers: [IntegrationController],
	providers: [
		IntegrationService,
		PrismaService,
		ScrapingService,
		CustomerIoService,
		JwtService,
	],
})

Es gibt auch den Analyzer, der Imports in einer vorhersehbaren Reihenfolge sortiert. Das ist optional, aber gibt jedem Datei-Header die gleiche Struktur. Details zur Reihenfolge gibt es hier.

Linting

Linting gibt uns einen Vorsprung, bevor Kunden Bugs finden. Jeder Linter hat natürlich eine kleine False-Positive-Rate, aber das Regelwerk schließt ganze Klassen von Fehlern aus, bevor sie überhaupt passieren!

Das vollständige Regelwerk von Biome findet sich hier.

Es hat triviale Checks wie no distracting elements (verbietet marquee und blink), aber auch deutlich fortgeschrittenere Regeln.

Meine Lieblingskategorie ist nursery, die veraltete JS-Features enthält, die durch modernere Syntax ersetzt wurden.

Linter-Warnungen: Beispiele

// 1. no banned types
code-block.ts:1:10 lint/complexity/noBannedTypes ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Don't use '{}' as a type.
  > 1 │ const n: {} = 0
      │          ^^

// 2. complexity
code-block.js:1:10 lint/complexity/noExcessiveCognitiveComplexity ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ⚠ Excessive complexity of 21 detected (max: 15).
  > 1 │ function tooComplex() {
      │          ^^^^^^^^^^
    2 │     for (let x = 0; x < 10; x++) {
    3 │         for (let y = 0; y < 10; y++) {

// 3. for .. of  vs  Array.forEach
code-block.js:1:1 lint/complexity/noForEach ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Prefer for…of instead of forEach.
  > 1 │ els.forEach((el) => {
      │ ^^^^^^^^^^^^^^^^^^^^^
  > 2 │   f(el);
  > 3 │ })
      │ ^^

// 4. no useless catch
code-block.js:4:5 lint/complexity/noUselessCatch ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ The catch clause that only rethrows the original error is useless.
    2 │     doSomething();
    3 │ } catch(e) {
  > 4 │     throw e;
      │     ^^^^^^^^

// 5. no useless ternary
const a = foo === 1 ? false : true; // einfach foo !== 1 schreiben

code-block.js:1:9 lint/complexity/noUselessTernary  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Unnecessary use of boolean literals in conditional expression.
  > 1 │ const a = foo === 1 ? false : true;
      │           ^^^^^^^^^^^^^^^^^^^^^^^^

Trivial, aber wichtig: keine unnötigen/schädlichen Typen
Nutzt Cyclomatic Complexity als Obergrenze für komplexen Code. Zu komplex → vereinfachen. Mehr Details unter McCabe Metrik. Wir sollten unter 10 bleiben (10 mögliche Datenpfade durch eine Funktion) und MÜSSEN unter 15 bleiben.
Sprachfeatures: for .. of .. ist leichter zu lesen als Array.forEach(...). Auch ein Performance-Vorteil!
Quasi toter Code ohne Funktion
Ein schönes Beispiel für FIXABLE-Lints: Dieser wird automatisch korrigiert!

... Und noch vieles mehr! Linter sollten in jeder Phase des Entwicklungsprozesses eingesetzt werden. Je früher, desto besser.

Biome im Editor

Für alle genannten Gründe sollten wir Biome überall einsetzen, wo es möglich ist.

Für die gängigsten Editoren hier die Extension/Plugin-Links, damit die roten Wellenlinien direkt verschwinden und Auto-Formatierung aktiv ist:

Allgemein und Vim/Emacs/etc.: biomejs.dev
WebStorm: plugins.jetbrains.com
VSCode: VSCode Marketplace
CLI:
- npm install --save-dev --save-exact @biomejs/biome
- Formatieren: biome format ORDNER/DATEI oder biome format --write ORDNER/DATEI
- Linten: biome lint ORDNER/DATEI oder biome lint --write ORDNER/DATEI
- Alle Checks (Format + Lint): biome check ORDNER/DATEI

Danach unbedingt:

Auto-Formatierung aktivieren
Die Linter-Fehler tatsächlich lesen und beheben

Magic Numbers

2024-11-22T10:00:00+00:00

Magic Numbers sind Zahlen oder String-Literale, die als Konstanten eingesetzt werden, ohne dass ihre eigentliche Bedeutung direkt erkennbar ist.

Dieser Artikel ist Teil einer Serie, die ich für die Arbeit schreibe, gedacht für Junior-Entwickler und externe Mitarbeiter. Wenn der Code generisch genug ist, verwende ich echte Beispiele aus der Praxis, ansonsten erfinde ich etwas ;).

Die Beispiele sind in TypeScript, da es von fast allen Entwicklern lesbar ist, die Konzepte gelten aber natürlich auch in anderen Sprachen. Python hat zum Beispiel keine echten "Konstanten", aber man kann reines UPPERCASE mit typing.Final kombinieren:

from typing import Final

MAX_KNOWN_POWER_SIZE: Final[int] = 9000

Das verhindert keine Neuzuweisung zur Laufzeit, aber ruff oder mypy werden sich beschweren.

Beispiele

HTTP-Status-Codes

// FALSCH
if (error.response.status === 409) {
    ...
}

// RICHTIG
import { HttpStatus } from '@nestjs/common';

if (error.response.status === HttpStatus.CONFLICT) {
    ...
}

Selbst wenn wir nicht alle HTTP-Status-Codes auswendig kennen, wissen wir jetzt, dass hier ein Konflikt vorliegt, ganz ohne Kommentare oder zusätzliche Komplexität.

Timeout

// FALSCH
setTimeout(() => {
    refreshData();
}, 300000); // Was bedeutet diese Zahl?

// RICHTIG
const REFRESH_INTERVAL_MS = 300000; // 5 Minuten in Millisekunden
setTimeout(() => {
    refreshData();
}, REFRESH_INTERVAL_MS);

Limits: Geschäftslogik

// FALSCH
if (user.age >= 18 && cart.total >= 50) {
    applyDiscount(cart);
}

// RICHTIG
const MINIMUM_AGE_FOR_DISCOUNT = 18;
const MINIMUM_PURCHASE_FOR_DISCOUNT = 50;

if (user.age >= MINIMUM_AGE_FOR_DISCOUNT &&
    cart.total >= MINIMUM_PURCHASE_FOR_DISCOUNT) {
    applyDiscount(cart);
}

Limits: Passwort

// FALSCH
if (password.length < 8 || password.length > 128) {
    throw new Error('Invalid password length');
}

// RICHTIG
const PASSWORD_LENGTH_MIN = 8;
const PASSWORD_LENGTH_MAX = 128;

if (password.length < PASSWORD_LENGTH_MIN ||
    password.length > PASSWORD_LENGTH_MAX) {
    throw new Error('Invalid password length');
}

Python Unplugged: Verborgene Batterien schürfen

2024-07-10T00:00:00+00:00

Slides (PDF): PDF herunterladen

Repository: github.com/dev-loki/europython2024-python-unplugged-slides

Worum geht es?

Ein Einsteiger-Vortrag über all die unbekannten Module der Python-Standardbibliothek.

Python-Grundkenntnisse erforderlich
Kein pip install PACKAGE nötig <3
Schwerpunkte: itertools, collections und functools
Ausflüge in contextlib, urllib und weitere Pakete
Einiges erfordert python3.12 (z.B. batched)

Das Repository enthält weitere Code-Beispiele, die:

detaillierter sind
ausführlich kommentiert sind
„vollständig" und ausführbar sind

(Vortrag auf Englisch)

Schneller entwickeln mit Test-Driven Development

2022-04-12T00:00:00+00:00

(Vortrag auf Englisch)

Original-Abstract

In diesem Vortrag zeige ich, dass TDD eigentlich kein Prozess für das Testen ist, sondern eine hilfreiche Entwicklungsmethode, die das lästige „Lass mal die Anwendung aufmachen und schauen ob das noch funktioniert" weitgehend eliminiert.

Nach dem Vortrag wisst ihr, wie ihr TDD in euren Workflow integriert und zu eurem Vorteil nutzen könnt. Wir räumen mit dem verbreiteten Missverständnis auf, dass TDD eine Testtechnik ist, und haben am Ende einen funktionierenden Prototypen.

Nachbetrachtung

In diesem Vortrag habe ich gezeigt, wie man einen minimalen URL-Shortener mit FastAPI/pytest im TDD-Stil baut. Es war fast erfolgreich, ich hatte nicht mit so vielen Fragen gerechnet ;).

Generell war ich viel zu nervös für eine gute Performance, und auch wenn mir Leute Komplimente gemacht haben, glaube ich, dass ich es deutlich besser hätte machen können!

Meine Erkenntnis: 1h 30min war zu wenig Zeit um wirklich tief in die TDD-Methodik einzutauchen. 2h wären ideal gewesen.

Mein Ziel: Das nach dem Jobwechsel (mit vielen neuen Dingen zum Lernen) verbessern.

Wird es einen richtigen Kurs geben?

Wahrscheinlich ja, für den nicht-konferenz-Einsatz würde ich aber lieber einen intensiveren 2-4h-Kurs machen, der auch Themen wie Datenbank-Migration und Deployment abdeckt.

Kann man es sehen?

Ja, wenn es sein muss :D. Aber Achtung: Mein Englisch war sehr eingerostet, da ich 1-2 Jahre lang kein Englisch gesprochen hatte. Ich bin super froh, dass es mit dem neuen Job wieder besser geworden ist :)

Advanced GIT: Git Worktree

2021-11-25T00:00:00+00:00

Eines der geilsten Features von Git. Gleichzeitig eines der am wenigsten benutzten Features.

Folgende Situation:

Ihr seid gerade an eurem feature/blubb_feature dran und dann kommt ein MR vom Kollegen, wo ihr bitte ganz schnell hotfix/make_that_users_dont_die_immediately reviewen sollt, damit das super flott live gehen kann. Leider ist der branch zu komplex um alles direkt im Gitlab zu machen.

Also wirklich auschecken und deep-dive in den Code...

Klassisches Vorgehen

git stash eurer Änderungen
git checkout hotfix/... um den Branch anzugucken und alles durch zu gehen.
Freigabe oder eben nicht

Viel besseres Vorgehen

Ihr habt git worktree eingerichtet (ist nativ bei git dabei) und habt sowieso schon folgende Ordnerstruktur:

project_name/
 - main/
 - develop/
 - feature/
   - blubb_feature/
 - hotfix/
   - make_that_users_dont_die_immediately/

Jeder Ordner ist quasi ein eigenes Git Repository. Aber alle teilen sich die Git Metadaten. Statt also euren Stand zu verlassen und komplett zu wechseln, reicht ein git worktree add BRANCH_NAME und ein Ordner, der auf einen zeigt, wird für euch erstellt.

Aber wie geht das jetzt?

Super simpel - wirklich :).

mkdir my_project (Projektverzeichnis erstellen) und via cd dort rein wechseln: cd my_project
Repository klonen (Achtung - hier ist die erste Besonderheit) git clone --bare GIT_URL .bare.
- Wir klonen also nur das bare Repository ohne einen Branch auszuchecken
- Diese Metadaten speichern wir im Order .bare (Durch den . am Anfang ist der Ordner unter MacOS/Linux versteckt)
Eine Datei my_project/.git erstellen und folgende Zeile eintragen:
```
gitdir: ./.bare
```
Damit weiß Git jetzt, wo sich unsere Repository Metadaten befinden
Ab jetzt funktioniert worktree perfekt:
- git worktree add main fügt unseren Main-Branch hinzu
- git worktree add feature/ABC_new_stuff_to_play feature/ABC_new_stuff_to_play um Branches mit / im Namen auszuchecken oder zu erstellen
- Tatsächlich könnt ihr aber auch beliebig im Dateisystem euren Ordner mit dem Branch erstellen. Das Format sieht in etwa so aus: git worktree add PATH BRANCHNAME

Weitere hilfreiche Befehle

Branch löschen:
- Variante 1: rm -r BRANCH_NAME und dann git worktree prune
- Variante 2: git worktree list Listet alle worktree branches.
Branch verschieben: git worktree move SOURCE DESTINATION

Stressfrei Programmieren mit Clean Code I

2021-09-02T00:00:00+00:00

Talk aktualisiert:

Auf englisch übersetzt
Fehler bereinigt
Dart spezifische Teile entfernt
An neuen Arbeitgeber angepasst :)

Folien

Wahlhelfer zur Bundestagswahl 2021

2021-08-23T00:00:00+00:00

Da ich die Kritik am Wahl-O-Mat selber kenne und teile, stelle ich hier die Alternative und Ergänzungen einmal vor.

Um vollständig zu sein/bleiben, hier meine persönlichen Kritikpunkte am Wahl-O-Maten:

Eindimensional -> Es fehlt die Abstufung oder auch eine "so nicht, aber so:" Option
Er gibt nur die Antworten der Politik wieder, aber nicht deren Handlung. Da wäre es echt fein, wenn diese beiden Dinge nicht so häufig auseinander driften würden.
Es wird nur ein beschränktes politisches Arsenal aus Thesen besprochen.

All diese Punkte haben auch irgendwie eine Berechtigung, da man natürlich nicht beliebig in die Tiefe gehen kann.

Trotzdem finde ich das Konzept des Wahl-O-Maten vom Grunde her super sinnvoll, da es Diskussion ermöglicht und ein grobes "Alignment" ermitteln kann. Wenn ich z.Bsp. eine 2% Übereinstimmung mit der AfD/Linken/Whatever habe, dann ist die Chance zwar nicht 0, aber doch sehr sehr gering, dass ich eben genau diese Partei wählen sollte.

Jetzt gibt es aber nicht nur den Wahl-O-Mat, sondern auch diverse alternative Wahlhelfer mit unterschiedlichen Ausrichtungen, die ich hier sammeln und vorstellen möchte

DeinWal.de

Link: deinwal.de

~~Noch ist der aktuelle "Wal"helfer nicht online~~, aber das Konzept von deinwal.de ist mein absoluter Favorit! Er vergleicht nämlich keine Wahlprogramme oder das, was Parteien gerade behaupten zu tun, sondern vergangene Abstimmungen und wie sehr das mit der eigenen Meinung übereinstimmt.

Auch wenn die BTW21 noch nicht frei geschaltet ist, kann man die alten BTW absolvieren und gucken inwiefern die großen (denn nur die sind enthalten) Parteien "damals" abgestimmt haben. Tipp: Europawahl 2019 und BTW2017 durchspielen.

Zu jeder Frage gibt es detaillierte Informationen und Verweise direkt auf die Pressemitteilung des Parlaments und Links zu abgeordnetenwatch sowie Wikipedia.

Jede Abstimmung wird mit Ja/Nein/Enthaltung bewertet und am Ende eingeordnet. Eine Gewichtung gibt es nicht.

Auf jeden Fall trotz der fehlenden Kleinparteien eine klare Empfehlung, weil es gerade den politischen Interessierten noch einmal enorm viele Zusatzinfos liefert.

Edit: Endlich ist die neueste Version von deinWal online. Das Grundkonzept ist geblieben. Auch der hauptnachteil ist leider geblieben: Es sind nur etablierte Parteien im Boot.

Wahlswiper

Link: voteswiper.org

Hier kann man, ähnlich wie es von Tinder bekannt ist, politische Statements gut/schlecht finden und am Ende die Übereinstimmung mit den Parteien finden.

Die gute Nachricht: Es treten 35 von 39 Parteien an, sodass man z.Bsp auch kleine Parteien wie die LIEBE Partei oder die Partei für Kinder, Jugendliche und Familien findet.

Als Bonus gibt es zu jeder Frage ein kleines Video und einen kleinen Text, welche sachlich das aktuelle Thema erklären. Jede Frage kann mit Zustimmung/Ablehnung oder Enthaltung bewertet werden. Zusätzlich können Themen, die einem besonders wichtig sind, doppelt gewichtet werden.

Auch der Wahlswiper ist für mich eine gute Empfehlung für Anfänger, da gerade Menschen, die sonst nicht so viel mit Politik am Hut haben, eine kleine Übersicht bekommen.

Sozial-O-Mat

Link: sozial-o-mat.de

Ganz speziell nur auf die Sozialpolitik fokussiert, gibt es den Sozial-O-Mat, welcher nur aufgrund von Sozialpolitik die eigene Meinung mit der der Parteien vergleicht. Dabei werden die vier folgenden Themengebiete abgedeckt:

Arbeit
Gesundheit
Famlie und Kinder
Migration

Betrieben wird der Sozial-O-Mat von der Diakonie. Jedes der vier Themen wird mit einer kurzen Einleitung begonnen, die die Relevanz hervorheben sollen.

Statt Videos oder Erklärungen wird dann jede These mit einer "Geschichte" unterstützt. Also statt Informationen erhalten wir etwas Menschennäher die Geschichte einer Person um diese These einzuordnen. Generell finde ich das Konzept zwar interessant, aber es gibt natürlich auch etwas die Richtung vor!

Jede These kann man als Positiv/Neutral/Negativ bewerten oder sie sogar überspringen um sie aus der Gleichung zu nehmen.

Gut für einen groben Überblick und für mich eher als Ergänzung gedacht.

Steuer-O-Mat

Link: smartsteuer

Einer der kürzesten und deutlichsten Wahlhelfer ist der Steuer-O-Mat. Sehr eindimensional wird ausschließlich das voraussichtliche Netto berechnet, was man mit diversen Parteien hätte.

Dazu gibt man einfach seinen Lohn ein und ggfs. noch den seines verheirateten Partners und kriegt am Ende eine reine Steuer-Wahlempfehlung.

Agrar-O-Mat

Link: agrarheute.com

Da - wie wir alle Wissen - die Lebensmittel natürlich nur aus dem Supermarkt kommen, betrifft dieser Wahl-O-Mat ausschließlich die Bauern ;).

Tatsächlich bezieht sich dieser Helfer passend zum Namen ausschließlich auf die Agrarpolitik und damit angrenzende Felder.

Zusätzliche Informationen gibt es nicht.

Jeder These kann entweder zugestimmt werden, neutral bewertet werden oder abgelehnt werden. Besonders wichtige Thesen können doppelt gewichtet werden.

Für mich interessant als Spielerei und Ergänzung, aber natürlich fehlt das Fachwissen, um wirklich Tief in die Agrarpolitik einzusteigen.

Klima-Wahl-Check

Link: klimawahlcheck.org

Auf das Klima selber gehe ich hier im Blog ja auch schon ein und werde definitiv noch deutlich mehr eingehen, aber ganz speziell nur auf das Klima bezogen gibt es den Klimawahlcheck.

Ingesamt ist dieser in die 6 Kategorien unterteilt:

Energie
Mobilität
Industrie
Gebäude
Klimagerechtigkeit & Klimaziele
Landwirtschaft & Artenvielfalt

Für mich persönlich einer der wichtigsten Helfer überhaupt, da es hier nicht nur, wie man gerne naiverweise denken möchte um das Klima geht, sondern wirklich direkt alle sozialen, wirtschaftlichen und wissenschaftlichen Themen mit abgedeckt werden.

Im Gegensatz zu den anderen Helfern wird jedes Thema mit einer Zustimmung von rot bis grün in 5 Stufen unterteilt. Zusätzlich können Thesen übersprungen werden.

Zu jeder These gibt es zusätzlich eine kurze Zusammenfassung mit dem Hintergrund zur Frage.

Anschließend sieht man ein Übersichtsbild und sieht die Parteien links/rechts/übereinstimmend von einem. Wenn man alle Kategorien durchgespielt hat, gibt es eine Gesamtauswertung.

Wie schon gesagt ist dieser Helfer für mich bisher der wichtigste, da die Klimaentscheidungen signifikant in Wirtschaft, Lebensqualität und sogar überleben mit einspielen.

Klare Empfehlung. Natürlich ;).

Waehlbar2021

Link: waehlbar2021.de

Deutlich mehr als nur ein 'o-mat bringt waehlbar2021 sowohl umfangreiche Informationen mit, als auch detaillierte Positionen von fast allen Parteien. Natürlich fehlt mal wieder die CDU/CSU in den Angaben. Die dachten sich wohl, dass, wenn Sie gar nicht antworten, kann denen auch keiner etwas übel nehmen.

Das beste Feature ist aber, direkt die Abgeordneten aus dem eigenen Wahlkreis mit ihren Stimmen zu sehen. Dazu gibt mein die eigene PLZ an und bekommt alle lokalen Kandidaten vorgeschlagen - inklusive der Übereinstimmungen in den einzelnen Thesen.

Abgeordneten die bisher nicht geantwortet haben, kann man hier direkt eine Nachricht mit dem Wunsch nach Transparenz hinterlassen.

Also auch hier natürlich eine klare Empfehlung zum Mitmachen und Informieren

Wahl-o-Mat

Link: wahl-o-mat.de

Endlich ist er da. Als wohl bekanntester Wahlhelfer hat der Wahl-O-Mat insgesamt 39 der antretenden 40 Parteien "interviewed" um zu zahlreichen Fragen Antworten zu finden.

Tatsächlich muss ich zugeben, dass ich den Wahlhelfer dieses Jahr ein klein bisschen besser als vorher finde. So gibt es nun zwar immer noch keine detaillierten Informationen zu den Fragen bzw. nicht genug Abstufungen, aber endlich haben wir die Möglichkeit sowohl direkt alle Parteien zu vergleichen (vielen Dank Volt dafür), als auch die Möglichkeit, anschließend mit den diversen Ergebnissen und deren Gewichtung herumzuspielen!

Tatsächlich kam zumindest bei mir auch ein anderes Ergebnis raus, als bei den anderen Wahlhelfern, was zumindest noch einmal mehr in die Breite geht.

Die Fragen sind tatsächlich auch recht vielfältig gestellt und treffen diverse Bereiche, wobei natürlich alle Bekannte wie z.Bsp. das Tempolimit fast überall auftauchen.

Ich kann (wie bei den anderen Wahlhelfen auch) auch hier eine klare Empfehlung aussprechen.

Fazit

Wenn es nach mir geht, sollte jede/r Wähler/in bis zur Wahl mindestens einen - besser aber direkt alle Wahlhelfer einmal gemacht haben, um eine Gefühl dafür zu bekommen, welche Parteien für was genau stehen.

Eines der dicksten Probleme (meiner Meinung nach) unserer Demokratie ist, dass die Parteien und Politiker mittlerweile gelernt haben, wie sie reden können, ohne verfängliche Aussagen zu treffen. Das verleitet viele Leute dazu, Parteien zu wählen, die selbst für die eigenen Interessen absolut ungeeignet sind. Die Wahlhelfer selber verändern diesen Fakt natürlich nicht, aber sie helfen dabei eine Kompetenz über die Inhalte der Parteien zu bekommen, ohne dass es nötig ist die Wahlprogramme zu lesen.

Meine Empfehlung wäre also die folgende "Formel":

alle Wahlhelfer durchspielen
Parteien die sich konsequent im letzten Drittel bewegen auszuschließen
Anschließend alle Wahlhelfer zu gewichten:
- 1/3¹ der Bewertung von deinWahl, da es das einzige Tool ist, welches über (womöglich leere) Versprechungen hinaus geht.
  
  Solltet ihr tatsächlich auch kleine Parteien in betracht ziehen, empfehle ich mit dem Wal zumindest ein Ausschlusskriterium zu bilden: Die zwei schlechtesten Parteien würde ich ausschließen.
  
  ¹ vorausgesetzt, ihr zieht sowieso nur die großen/etablierten Parteien in Betracht
- 1/3 aus den anderen Helfen generieren, indem wir jeder empfohlenen Partei Punkte geben.
- 1/3 dann auch selber aus Artikeln generieren. Dabei ist es wichtig, sich weder von Tagesschau/ZDFHeute&Co noch (und das ist wichtig!) sich von Facebook/Whatsapp-Gruppen/usw beeinflussen zu lassen.
Nehmt DIE Dinge, die euch wichtig sind (Rente, Steuern, Klima, was auch immer) und befasst auch ausdrücklich auch mit den Gegenpositionen und Argumenten. Damit stellen wir sicher, dass wir keine reine Bauchentscheidung für eine der wichtigsten Wahlen der letzten Jahrzehnte treffen.

Klimakatastrophe I: Was ist

2021-08-19T00:00:00+00:00

Zu allererst und am wichtigsten: Ich schreibe diesen Artikel für Familie und Freunde mit dem Ziel, dass ich nicht ständig zum "nervigen Klimaaktivsten" werden muss.

Es geht mir also darum, an einer Stelle möglichst viele Klimafakten zusammen zu tragen und zu erklären, warum mir eine radikale Änderung von Politik und Zusammenleben so wichtig ist.

Diese gesamte Problematik ist echt komplex und umfangreich, weswegen ich versuche sie in 3 Artikel zu splitten:

Was ist (Dieser Artikel)
Was kommt (und zwar in einer Zeit, die wir auf jeden Fall noch erleben werden und Ophelia/Auroras Kernlebenszeit ausmacht)
Was wir tun müssen (Nur der absolute wissenschaftliche/wirtschaftliche Konsens und das Minimum um die Auswirkungen zu minimieren)

Das abstrakte Konzept vom sogenannten Klimawandel (eigentlich Klimakatastrophe) ist ja mittlerweile jedem bewusst und die groben Auswirkungen haben wir alle schon einmal gehört: Meeresspiegel steigt, es wird heißer und auch die Wahrscheinlichkeit für Extremwetterereignisse steigt.

Aber das ist leider nicht das komplette Problem bzw. macht meiner Meinung die echten Folgen nicht klar genug.

In diesem ersten Beitrag möchte ich darüber reden, was für Auswirkungen wir heute schon in Deutschland spüren und als ein Fernglas für Deutschland in die Zukunft auch über das, was wir in der Welt jetzt schon sehen. Das sind alles messbare Dinge und die allermeisten wurden wissenschaftlich exakt so vorhergesagt. Leider meistens für ein paar Jahre später in der Zukunft. Denn eines ist hier leider klar geworden: Fast alle Prognosen waren deutlich zu optimistisch.

Folgen in Deutschland

Am nächsten sind vielen wohl die Folgen direkt im eigenen Land. Kurz stichpunktartig zusammengefasst:

Hitzetote haben sich verdoppelt
Erste Seen sind bereits ausgetrocknet, andere von Blaualgen betroffen
Wirtschaftliche Schäden in Milliardenhöhe
Ernteausfälle
Wasserknappheit
Zoonosen
Waldsterben

Hitzetote

Seit 1955 ist die Anzahl der Hitzetoten um 120% gestiegen. Das sind im 4 Jahreszeitraum 2014-2018 ungefähr 12000 gewesen. Ein Großteil dieses Wachstums ist in der Zeit zwischen 2004 und 2014 - also dem letzten Zeitabschnitt passiert. Um einen Vergleich zu bringen: Das sind 1.5x mehr Tote als im gesamten innerdeutschen Verkehr. Wobei das nicht ganz fair ist, da der Verkehr einen nicht unwesentlichen Beitrag zu genau diesen Toten mit beiträgt.

Ausgetrocknete Seen & Blaualgen

In Brandenburg sind bereits jetzt die ersten Seen ausgetrocknet. Wo früher ein See war ist jetzt (noch) fruchtbare Wiese. Deutschlandweit sind viele weitere Seen betroffen bzw werden in den nächsten 20 Jahren austrocknen, nur um dann alle paar Jahre von Hochwasser gefüllt zu werden.

Die Seen, die nicht austrocknen sind bereits jetzt zunehmend im Sommer von Cyanobakterien betroffen. Ich erinnere mich noch an meine Kindheit und wie wir bei Oppum im Baggersee schwimmen waren. Mittlerweile wird vor Baggerseen zunehmend gewarnt.

Um ganz ehrlich zu sein: Für die Bakterienbelastung ist die Klimatransformation nicht die einzige Ursache. Aber das Thema der Landwirtschaft ist alleine für sich so komplex und umfangreich, dass ich das in meinen Beiträgen hier erst einmal weg lassen werde.

Wirtschaftlicher Schaden

Tatsächlich ein echt wichtiges Thema. Nicht weil ich das jetzt persönlich so toll finde, sondern weil man ständig liest und hört, wer das alles bezahlen soll bzw. dass die Politik (primär CDU/SPD) versuche, das Klima mit der Wirtschaft in Einklang bringen will.

Das halte ich für zutiefst unehrlich, da der Politik durch zahlreiche Berater aus Wissenschaft und Wirtschaft schon lange nahegelegt wird, dass Klimaschutz auch Wirtschaftsschutz ist. Das einzige was leiden würde, wären kurzfristige Quartalsergebnisse. Auf lange Sicht ist Klimaschutz billiger - Menschenleben und Lebensqualität mal komplett ignoriert.

Mal in konkreten Zahlen

Dass wir nicht nur nicht in den Klimaschutz investieren, sondern gerade die CDU und insbesonderen Altmaier aktiv den Klimaschutz behindern, macht es nicht leichter. So ist aus einer Industrie mit 80k Arbeitsplätzen der regenerativen Energien, bei der wir weltweit Vorreiter waren, praktisch nichts mehr übrig. Wenn selbst die WELT, welche mit Klimathesen glänzt die primär vom AFDP nahem "EIKE Institut" abgeschrieben wurden, das bemerkt, dann ist wirklich Land unter.

Ernteausfälle

Es kann natürlich eine Anomalie gewesen sein, aber letztes Jahr (2020) lagen die Ernteausfälle zwischen 30 und 50 Prozent. Fast komplett durch die Dürre bedingt. Ein Faktor, der sich definitiv noch zuspitzen wird. Dieses Jahr ist alles extrem feucht, sodass sowieso schon geschwächte Pflanzen/Bäume/etc. direkt von der anderen Seite mit Fäule zu kämpfen haben.

Bisher wurden diese Umstände durch den Fakt abgefedert, dass wir sowieso schon zu viel wegschmeißen bzw importieren konnten. Aber gerade unsere Gemüse/Obst-Importländer wie z.Bsp. Spanien oder die Niederlande werden durch Hitze (Spanien) oder Überflutungen (Niederlande) noch mehr zu kämpfen haben als wir. Die Niederlande sind bereits jetzt unterhalb des Meeresspiegels, während sie sich gerade noch so über Wasser halten, weil durchgehend Pumpen im Einsatz sind.

Wasserknappheit

Letztes Jahr haben wir das in Nieder-Beerbach überdeutlich selber gemerkt, dass einfach mal zwei Wochen Wassersparen angesagt war. In Niedersachsen gab es erste Fälle von Wasserverteilung durch die Feuerwehr, weil die Becken einfach leer sind.

Durch unsere geographisch überaus günstige Lage wird es auch in der mittelfristigen Zukunft nur um wenige Tage bis Wochen gehen und zusätzlich örtlich begrenzt sein, aber die Auswirkungen werden trotzdem gravierend und sorgen für Warnungen von Wasserwerken und Forschern.

Waldsterben

Zusätzlich zur Trinkwasserknappheit sind gerade 1/3 unserer Wälder dabei zu sterben. Die Trockenheit alleine reicht häufig aus und wo diese nicht reicht helfen "Schädlinge" dabei unseren Wäldern den Rest zu geben.

Die Folgen sind nicht einfach nur "weniger grün" oder, dass wir weitere CO₂ Filter damit entfernen, sondern rapide abnehmende Biodiversität, Bodenschäden (wie z.Bsp. Erdrutsche) und gravierendere Wetterphänomene, die nicht mehr durch Wälder geblockt oder geschwächt werden.

Eine Fläche von ehemals gut 12 Millionen Hektar hat in den letzten 20 Jahren mal eben 300.000 Hektar schon eingebüßt - und da sind die Kohlestrom-Wälder noch nicht eingerechnet. Ganz konkret sind nur ~21% unserer Bäume überhaupt noch gesund.

Zoonosen

Corona war nicht die erste Zoonose und wird nicht die letzte gewesen sein. Was ohne menschlichen Einfluß eine Sache von Jahrhunderten war, wird häufiger vorkommen. Sowohl meine Generation wird noch mindestens eine weitere Zoonose wie Corona mitbekommen und für meine Töchter wird es Fall der Gewohnheit.

Die Bundeszentrale für politische Bildung selber geht auf ihren Seiten in die Details ein, aber wie so häufig gilt dann doch eher, was RWE oder die heimische Stahl- und Autoindustrie sich wünscht.

Während wir also noch mit SARS-CoV2 kämpfen sind, gibt es schon weitere Erreger diverser Art die auf dem Weg zu uns sind. Nicht nur, dass unsere Bemühungen beim Klima/Menschenschutz zwischen mangelhaft und ungenügend sind, treten wir als Menschheit noch einmal nach, indem wir primär durch unsere Fleisch- und Tierindustrie multiresistente Keime züchten.

Weltweite Folgen

Wenn wir vom Klimawandel reden, reden wir häufig auch von den s.g. Kipppunkten. Davon haben wir bisher in etwa 16 identifiziert. Ein Kipppunkt ist eine Stelle, ab der ein Prozess in Gang gesetzt wird, den wir nicht wieder umkehren können. Ab dieser Stelle läuft's halt und zwar in den meisten Fälle mit selbstverstärkender Wirkung.

Permafrost

Einen der Kipppunkte die wir bereits erreicht haben, ist dass Weltweit der Permafrost auftaut. Dabei werden große Mengen Methan freigegeben, was die Erwärmung natürlich zusätzlich weiter beschleunigt. Methan ist schon am ehesten das, was uns nachhaltig schadet, aber auftauender Permafrost hat noch deutlich mehr Probleme.

So berichtet zum Beispiel die online Variante des Geomagazins von mehreren Studien, die über weitere Bakterien, Viren und mehr berichten, die sich dort verstecken. Das allermeiste wird harmlos sein, aber selbst harmlose 15.000 Jahre alte Erreger können unser Immunsystem extrem empfindlich treffen.

Ein echtes Beispiel gab es zum Beispiel bei der Übersiedelung nach Amerika, wo europäische Kolonisten ihre Krankheiten mitbrachten und ganze Stämme auslöschten. Nicht weil diese Krankheiten an sich so gefährlich waren, sondern weil die Immunsysteme der American Natives nicht vorbereitet waren.

Regenwald

Der Regenwald wurde und wird fälschlicherweise noch als die grüne Lunge der Erde bezeichnet. Leider haben wir dieses Jahr den Punkt erreicht, wo aus dem Regenwald mehr(!) Treibhausgase austreten, als er absorbiert. Das ist extrem bitter und ist in diesem Fall zu fast 100% auf Fleischkonsum zurück zu führen.

Um es noch einmal deutlich zu sagen/schreiben: Wir haben dieses Jahr den Punkt erreicht, wo der Regenwald NICHT mehr die grüne Lunge ist. Ganz trivial bedeutet das, dass wir unsere Schulbücher umschreiben müssen, praktisch heißt das, dass wir eines der wichtigsten Ökosysteme des Planeten nachhaltig vernichtet haben. Und das für stark veredeltes Soja?

Ironischerweise wird hier auf die Sojafelder und böse Veggies verwiesen, dass vom weltweiten Soja nur 6% in diversen Veggieprodukten landet und der Rest zu Tierfutter verarbeitet wird, wird gerne verschwiegen. Vom Regenwaldsoja landet auf direktem Wege in deutschen Mägen sowieso praktisch nichts, da hierfür die Produkte halbwegs regionale Erzeuger verwendet werden. So braucht eine Kuh rund 12kg Soja um ein Kilo Fleisch zu erzeugen. Schwein/Geflügel ist da zum Glück deutlich genügsamer.

Aber wir können doch nicht die Welt retten

... wie bewegen wir die anderen dazu mitzuhelfen?

Müssen wir nicht. Wir müssen hauptsächlich einmal anfangen, nicht mehr zu bremsen. In Europa sind wir DIE Bremse schlechthin.

Obwohl wir nur 1% der Weltbevölkerung stellen erzeugen wir rund 2% der Klimagase. Da sind in China/Taiwan produzierte Produkte oder Diensleistungen wie Server&Co aus dem Ausland, die für den deutschen Markt bestimmt sind und uns eigentlich zugerechnet werden müssten, noch nicht einberechnet.

Wir sind in Deutschland pro Kopf noch deutlich vor China, welches bei rund 5t CO₂ liegt, während wir bei durchschnittlich 11t sind. Doppelt so viel wie das schlimme China. Bei über 200 Ländern sind wir momentan mit dem absoluten Ausstaß unter den Top10. Wollen wir wirklich, dass fast 200 Länder mit der gleichen Argumentation kommen? Würden wir unseren Kindern "aber die andern!" als Argument durchlassen?

Edit: Abschließend bleibt hier noch einmal diese Wunderbare Zusammenfassung von Quarks des ersten Teilberichts vom IPCC. Insgesamt wird es 3 Berichte und 1 Zusammenfassung geben. Wichtig hierbei ist, dass die Berichte schon fertig sind, aber erst 2022 veröffentlicht werden, weil die Regierungen noch einmal Einfluss nehmen können. Eine Zusammenfassung des Leaks aus Teil 2 (sollte erst Januar 2022 kommen) hat der Spiegel.

Relevant ist hier vielleicht auch, dass der GRUND für diesen Leak ist, dass die Wissenschaftler Angst haben, dass der Bericht von den Regierungen verwässert wird.

whoami

2021-08-17T00:00:00+00:00

#whoami

Vater
Ehemann
Entwickler
Wissenschaftsfreak
Klimafreundlich (Familie endlich seit 2021 naiv CO₂ neutral)