dracoblue.net

This post documents Week 1 of a research project I call TopicWatchdog: an end‑to‑end, reproducible pipeline that (a) collects German political short videos, (b) transcribes them, (c) extracts topics and claims with timestamps, and (d) persists everything in BigQuery for transparent, long‑term analysis.

The focus is on methods and reproducibility, not on polished production code. The snippets below are meant as guidance scaffolding, but already allow you to build a similar pipeline.

When working with payload cms, I sometimes need to check what is in the system collections of payload.

There is e.g. payload-preferences or payload-migrations. Since 3.0 there is also payload-jobs for the neat queue system and payload-locked-documents for the document locking.

You can find in the directus docs a good documentation how to run a build of directus in docker. For developing and contributing to direcuts itself there is a good documentation on running directus locally.

But if you want to develop a directus endpoint extension locally, you might want to use the "breakpoint" feature of your IDE (e.g. vscode). Without the need to run the entire directus stack with pnpm in development mode.

When I am using windows for development reasons in combination with wsl it is usually pretty good experience. As long as you don't try to mount a windows directory into the linux subsystem, but use the storage directly there - it's nice!

The official vscode extension for wsl usually integrates nicely with visual code.

But today I experienced a very bad performance of vscode and the windows system. A short htop / taskmanager call showed: All CPUs have been in use for 100%. The process eating all resource was called: .vscode-server.

The other day a friend of mine was using google-auth-library-php in combination with google-cloud-php-pubsub and wanted to set the path for the google credentials file via GOOGLE_APPLICATION_CREDENTIALS in .env.

So we figured that this did not work anymore in the newer version of dotenv (see commit in 4.3) the default value for use_putenv changed to false. And in symfony 5 there was a breaking change to switch use_putenv from true to false (see the putenv deprecation pull request.