DEV Community: George Shuklin

The tiny twitch which wretch

George Shuklin — Sat, 04 Apr 2026 08:53:52 +0000

Is Go a good language? (a can of worms opens and closes).

No, I mean, for the end-user? It turned out that there is one stupid thing which was done odd at argument parsing which makes Go a 'snowflake' language.

Single-dashed arguments. I presume there were some arguments from developers to allow back single-dash long args (-hello) instead of double-dash ones (--hello), but it's just made it... special.

In a bad way. We accept tar madness (tar vxzf) out of grand-dad respect, and the same for ar. But why does a modern language deviate? To set a new standard? Okay, they did it. Now we have a 'go-specific snowflake standard' vs the rest of the software stack. Why? Just because someone thought it would be a good idea to do it ...differently. Now, we have a set of software that has special needs.

Every time I look up which language a new thing was written in, Go is always, like, 'meh'. Only and only because of their stupid argument parsing library.

... And gotemplates, but this is more rare and more app-specific. But arguments are... like, why? -why?

The most useful command in the age of agentic

George Shuklin — Fri, 27 Mar 2026 10:45:13 +0000

I love when this 'thing' do stuff while I'm doing something else. We discussed, corrected plan, or it is in the middle of investigation, anyway, it's 5+ minutes. And I want to close the lid of the laptop, but continue this thing to work.

The modern systemd allows me that. This simple script prevent laptop to go to sleep by timeout or by closed lid, as long as it's running. Press Ctrl-C to terminate.

systemd-inhibit --what=handle-lid-switch:idle --who='manual' --why='nosleep script' sleep infinity

Bingo, you can close lid and have stuff continue to be done.

Someone draw a picture, I updated it

George Shuklin — Thu, 12 Mar 2026 14:37:15 +0000

The main difference between computer science and real computers is side effects

George Shuklin — Sat, 17 Jan 2026 09:12:27 +0000

(from a comment)

The main difference between computer science models for computers and actual computers is side effects.

Side effects is what make you able to observe results of computation. There is nothing in CS which allows you to have 'an observer'. Even 'tape' in Turing machine is something you observe, it's a side effect, but it's so perfect, that it always works, there are no jams, no IO timeouts, etc, so it's accepted as perfection (it's also infinite). Same for the final state of machine, which you somehow magically 'observed'.

So, computer science study computing. And then there are real things out there doing mostly side-effects. For which 'less computation is better'. The more side effects you do (compare to the computations), the better is your program. If you can print (side effect) the answer in 1ms, your program is superior to the program which do computer science things (compute) for 1 minute before printing the same result .

No one wants computing, we want side effects. We tolerate computing only because there is no other way to make lights to blink in the proper order. https://xkcd.com/722/

So, every reasoning in CS does not really care about side effects (even if they are studied), CS is all about computing, and computer application is all about side effects.

So, there is a gap in terminology, different focus, different values, different everything. It is the reason software engineering (the computer part of it, humans aside) is so different from academia writings in any programming language (incl. programming languages itself).

Vector's VRL introduction (chapter 2)

George Shuklin — Sat, 11 Oct 2025 07:32:40 +0000

In a previous chapter we learned how to run VRL and made our first "Hello World" application.

It was mostly trivial, except for the unusual use of a "dot" (e.g., .message).

The Dot

The VRL program is a bit different from usual programming languages. The main convention is that there is a . variable, which contains the event (for which the VRL application is running). The value of . at the end of the program execution is the return value.

. is not just a variable name. As you've noticed, you can access it the way you do in most other programming languages (object.property), but when you access the content of the dot, you don't need to write ..message; you write just .message. By the way, in VRL, if you have other variables, you can do variable_name.property too.

Let's look at our previous program, which was cleaning stuff from the dot.

.message = "Hello World"
del(.timestamp)
del(.host)
del(.source_type)

We are modifying the event. But we can do better.

. = {"message": "Hello World"}

Or like this:

. = {}
.message = "Hello World"

In those two examples we are not modifying .; we are replacing it with new content consisting of the object (also called a dictionary, if you are coming from a Python background). We either construct it in place (JSON notation) or create an empty object and set (create) a key message with the value "Hello World".

Assignment and Reassignment

Reassignment rules allow using . in expressions that replace . (or any other variable).

. = {"message": "Hello World", "old_message": .message}

If we run it with input test, we get the expected result:

{
  "message": "Hello World",
  "old_message": "test"
}

We also can create new variables with a simple =.

old_dot = .
. = {}
.message = "Hello World"
.old_message = old_dot.message

Each assignment is a deep copy (that means, it copies all data recursively).

temp = .
. = {}
.message = "Hello World"
.old_dot = temp
temp.message = "replaced"

With the same input (test) we get this output. Note, there is no "replaced" in the output, because we copied temp into .old_dot before changing temp.message.

{
  "message": "Hello World",
  "old_dot": {
    "message": "test"
  }
}

Some ergonomic hints

You can try those examples from the console, with the command line:

vector --config example.yaml  -q|jq .

(put code examples into example.yaml.)

You also can try the VRL playground: https://playground.vrl.dev/

Please note that my initial example contains this source:

sources:
  stdin:
    type: "stdin"

And it internally creates an object with a few fields: host, message, test, source_type, stdin, timestamp.

If you decide to run code from the playground, you need to create an event (not just the word test), so the minimal input for the playground is {"message": "test"}.

There can be a bit of confusion between not-a-JSON input and the event object at the VRL start, but it's easy to explain and understand:

Everything Vector passes between sources, transforms, and sinks is always an object. Sources can take non-structured input (like stdin or exec), but they wrap unstructured text into an object. They also append metadata; that's how you get timestamp and host.

Second: VRL allows you to put spaces and newlines in most places (but not all!).

These are two equivalent programs:

. = {
        "message": "Hello World",
        "old_dot": .
      }

and

. = {"message": "Hello World", "old_dot": .}

But this is NOT a proper VRL program:

.
  = 
    {}

You also can have a trailing comma in objects:

. = {
        "message": "Hello World",
        "old_dot": .,
      }

This may be silly at first glance, but it makes git diff much cleaner if you decide to add a line after the last one:

. = {
        "message": "Hello World",
        "old_dot": .,
        "something": "else",
      }

My advice is to use a trailing comma because it reduces syntax errors when you move lines around or add/remove them.

In the next chapter we will discuss types, fallibility, and progressive typing.

Vector's VRL introduction (chapter 1)

George Shuklin — Thu, 09 Oct 2025 18:16:25 +0000

Preface

There is a program to process events (metrics, logs, traces) from different sources (files, scripts, scraping, HTTP servers, syslogs, etc.) into different sinks (Prometheus exporter, remote HTTP, files, etc.), while transforming it in different ways.

It's called Vector. And it is amazing by all means, except one: there is no tutorial for VRL. There are docs on transforms, sinks, sources; there is a language reference; but there is no proper tutorial for the main feature of that program, the built-in language to do transformations, called Vector Remap Language.

I found myself in a situation when I needed to write a complicated transformation (~0.05 kloc), and to do so I learned VRL for real.

Because I found no introductions to VRL, I decided to write my own.

Minimal required onboarding into Vector

While I won't talk much about other transforms, sinks, and sources, I need to give enough background about them to use VRL.

Vector has sources, transforms, and sinks. Events flow from sources, through transforms, into sinks. Events are always moving forward. They can be "fanned out" into multiple transforms/sinks or can come from multiple sources/transforms, but they never create a loop (never go back). It's called a DAG (directed acyclic graph).

Each transform or sink has a list of "inputs" to previous sources or transforms.

This is an over-engineered cat command. It reads data from the stdin source and writes it to the stdout sink:

sources:
  stdin:
    type: "stdin"

sinks:
  stdout:
    type: "console"
    inputs: ["stdin"]
    encoding:
      codec: "text"

To run it we run Vector --config example.yaml.

Everything we put into stdin gets output to stdout (but will be normalized in terms of Unicode characters, so it's not a true cat program).

This is almost enough for our goals. One more thing: we will create a remap transforms in the middle. A VRL description is coming, but for now just believe me that empty text is a valid VRL program: it changes nothing, and the incoming event is passed further.

This is our tutorial setup; we will use it to learn VRL. The actual VRL program is written inside the source stanza of the our_example transforms.

sources:
  stdin:
    type: "stdin"

transforms:
  our_example:
    inputs: ["stdin"]
    type: remap
    source: ""

sinks:
  stdout:
    type: "console"
    inputs: ["our_example"]
    encoding:
      codec: "json"

This creates a very simple DAG: stdin->our_example->stdout. In this chain of articles we will focus on the source part of our_example. This is where VRL happens. (Note: you can have multiple remap transforms, and each will have its own VRL program.)

Note: we changed the codec for sink stdout to json; this will help us see what exactly we have done.

What is 'event'?

If you run the previous program, you will see this as output (plus some log info from Vector itself; ignore it). I split lines into a few, but you will see it as a single line if you run it yourself.

{
  "host":"shuttle1",
  "message":"test",
  "source_type":"stdin",
  "timestamp":"1985-10-09T17:43:54.287916009Z"
}

I typed test into stdin and got this output. This is an event, and it has type log (we will talk about logs vs. metrics a bit later).

Note that I typed only test, but we got a lot of metadata — hostname, timestamp, source information — and the message, the stuff I typed.

Events come from sources. If they pass through a transforms of type remap, the corresponding VRL program from the source will run. A single event contains either a log line, or a sample for a series, or a trace. VRL programs never run by themselves; they always require an event to come from a source.

To save myself on long listings I won't show the full config for Vector anymore, only the content of the source (the VRL program).

Hello world

Because we can't just "run" a VRL program, we need to pass something into stdin. To make it easier, I run it like this:

echo 'test'|vector --config example.yaml

or even like this

echo 'test'|vector --config example.yaml -q

(the latter removes most of the logs from output)

So, let's write a hello world program. (Note, I show only the source content for the transforms our_example.)

.message = "Hello world"

Note: YAML allows writing multiline strings, so my transform looks like this:

transforms:
  our_example:
    inputs: ["stdin"]
    type: remap
    source: |
        .message = "Hello World"

(just keep indentation correct and you may pretend YAML does not exist)

If we run it with a command line (see above), we get...

As expected:

{
  "host": "shuttle1",
  "message": "Hello World",
  "source_type": "stdin",
  "timestamp": "1985-10-09T18:02:33.317302641Z"
}

Now, let's run Vector without an echo | before:

vector --config example.yaml  -q|jq .

and type two lines of some text (in my case test and no!):

test
{
  "host": "shuttle1",
  "message": "Hello World",
  "source_type": "stdin",
  "timestamp": "1985-10-09T18:03:51.444177436Z"
}
no!
{
  "host": "shuttle1",
  "message": "Hello World",
  "source_type": "stdin",
  "timestamp": "1985-10-09T18:03:52.829102974Z"
}

As you can see, every input line caused a new run of our VRL program, which replaced the message with "Hello World".

Note: we kept our metadata intact. And we got a timestamp.

Let's clean it a bit:

.message = "Hello World"
del(.timestamp)
del(.host)
del(.source_type)

Now, if we type two lines, we get only the message:

test
{
  "message": "Hello World"
}
test
{
  "message": "Hello World"
}

We will learn about VRL in the next chapter. Also, the thing I did (removing almost all metadata) is not recommended; it can break many sinks. We do it here just to get a taste of how VRL looks.

Basics of the basics of VRL

As you can see, the VRL program consists of zero or more expressions. There is no ';' , and spaces are not important. If we call a function, arguments are in brackets , strings are in quotes, = is the assignment operator. There is something fishy about . at the beginning of things, but that's the topic for the next chapter.

In the next chapter: The Dot, variable assignment.

Good practices for Just: no '../' in paths.

George Shuklin — Sat, 06 Sep 2025 09:57:37 +0000

If you don't know, Just is https://just.systems/, the beautiful well-thought replacement for make as 'small scale executor'. It does not replace make as a build tool (handling creation dates for files, etc), but it does so for every .phony stuff from a Makefile.

As for most tools, the usage starts small, but starts to spiral into chaos as line count grows. My current project I work on has about 300 lines in Justfiles. Very dense lines, with average recipe about 3–5 lines, and the magic living between recipes (one recipe is calling other or dependent on other recipes).

The chaos must be resisted with order and rules. A good rule is the best practice.

I don't have 100% assurance in things I write now, but I feel, I can call them at least 'good practices'. There are few now, but they start to accumulate as I correct my previous design mistakes and see arising problems.

Rule 1: No ..

We start with cwd (current working directory) been set to the path where used Justfile is placed.

├── Justfile
├── somedir

We go into somedir, type just myrecipe and our working directory is the dirictory where Justfile is, not 'somedir'.

This is nice and we can use it for relative pathes. There is nothing bad in writing something like that:

deploy:
  ansible-playbook playbooks/deploy.yaml -i inventory/

Even if we are calling just deploy in the playbooks directory it will work as expected, we will go 'up' to run this command and all pathes will point to the expected files.

There are also [no-cd] and [cd dir] attributes.

But... Sometimes we need to change directory.

deploy:
   cd ansible && ansible-playbook playbooks/deploy.yaml -i ../inventory/

We changed the structure. Now there is ansible/playbooks/ and /inventory and we need to cd to ansible before running Ansible (because there is ansible.cfg there and all other stuff).

But inventory is outside of ansible (for whatever reasons). And we need it.

Simple solution is '..'. Which quickly become:

cd production/deploy/ansible && ANSIBLE_INVENTORY=$(realpath inventory/),$(realpath ../environments/{{ environment }}/ansible/inventory) -e @../../../sources/data {{ args }}

Can you see the problem? Too many ...

If you decide to move stuff around during refactoring, you will have to recalculate those '..', and it's hard, because you need to reason on state machine jumping between directories.

Solution? Use {{ justfile_directory() }}.

It is the absolute path. Except when you need relative path for external reasons, it's always pointing to the proper place, even if you pass it as an argument to the utility which run from a different directory.
It is the relative path in sense, than clonning a repo into a different directory or moving stuff around keeps relative links unbroken.

Best of both worlds.

Let's look to the good practice of using {{ justfile_directory() }}.

cd production/deploy/ansible && ANSIBLE_INVENTORY={{ justfile_directory() }}/production/deploy/ansible/inventory,{{ justfile_directory() }}/production/environments/{{ environment }}/ansible/inventory) -e @{{ justfile_directory }}/sources/data {{ args }}

(I may made some relative mistakes while writing it, it hurts my brain to think about original paths).

Result is much more readable (although, longer). We always can see where file is relative to the justfile, and there is no 'relativity' of (working directory after cd, relative paths for Ansible, etc, etc).

For every utility it is absolute path, no thinking required.

For developer it's all relative paths, relative to a single location - the placement of the Justfile.

If we decide to remove 'production' from the path, we don't need to think which ../.. to reduce and which to keep. It all stays intact.

I will post more good practices as I find the specific cases.

Getting pure output from Ansible

George Shuklin — Sat, 09 Aug 2025 13:01:48 +0000

There are moments when you want Ansible to stop printing anything own and just to show output of the remote command.

Like ssh user@server command, but with all Ansible bells and whistles, with custom ssh arguments, transports, etc, etc.

I'm talking about the ansibile binary, not the ansible-playbook, although, with some tinkering, it's possible to use this trick with ansible-playbook too.

Foundation for tricks:

Use raw module (disaANSIBLE_LOAD_CALLBACK_PLUGINS=1 ANSIBLE_STDOUT_CALLBACK=json ansible -i localhost, -m raw -a 'cat /etc/passwd' all -c local | jq -r '.plays[].tasks[].hosts | to_entries[] | "(.key):\n(.value.stdout)\n"'bles AnsiballZ mechanism)
Use json output (which allow to extract stdout without using unsound grep expressions).
Process it with jq.
Ask jq not to print quotes for string value.

Here it is:

ANSIBLE_LOAD_CALLBACK_PLUGINS=1 \
ANSIBLE_STDOUT_CALLBACK=json \
ansible -i localhost, -m raw -a 'cat /etc/passwd' all -c local \
| jq -r '.plays[].tasks[].hosts[]?.stdout'

Disection:

Env variables says ansible to load callback plugins and to use json callback plugin (output).
-i localhost, and -c local are not important. Use a proper inventory here if you need. localhost here just for an example.
-m raw -a command is usual ansible invocation
-r for jq removes quotes from a string.
Expression .plays[].tasks[].hosts[]?.stdout scans all hosts in all tasks for all plays and prints stdout.

Why do you need it?

Well, the thing I wanted to do was to get a secret file from a remote server and encrypt it locally on the host using sops. I can use community.sops.sops_encrypt module, but it require multiple steps to do, and secrets are nasty to debug, so I don't want to do those steps.

A 'simple' ansible call with | sops -e is require less attention.

But, it requires this 'pristine output' from ansible to avoid mangling the content, so, I had to invent this quirk.

How to retry block in Ansible

George Shuklin — Tue, 05 Aug 2025 09:19:13 +0000

Normally you can't. But, if you really want, you can.

Here is how.

Move that block into separate tasklist. E.g. foo.yaml.
import it: - import_tasks: foo.yaml.

Now, the magic. The content of the foo.yaml

- block:
  - set_fact:
      count: "{{ count | d(0) + 1 }}"
  - name: Arbitrary number of tasks here which can fial
    command: /bin/false
    ...
  rescue:
    - fail:
      when: count > 3
    - include_tasks: foo.yaml

How it works.

foo is run.
set fact set counter to 0 (because there is no counter)
your tasks run. If they finish, block finish and everything is good.
If any of your task fails, rescue part will be executed. If counter is less than 3, fail is skipped and foo is included. It is the same file as you imported, this is self-recursion.
Counter become + 1
Try again. ...
If count is too high, fail is executed and recursion stop.
If at any count (before fail) block succeed, rescue section finishes, and recursion returns back and it continue to run as it wasn't failed at all (the desired property of the retry).

It is terrible, but beautiful.

Double force reboot

George Shuklin — Sat, 02 Aug 2025 08:48:24 +0000

Today I've learned that systemd, actually, supports hard reboots.

systemctl reboot --force --force

From the man page:

If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the halt operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager has crashed.

This is the closest equivalent of echo b > /proc/sysrq-trigger I can find.

Elegant way to assert if env variable is defined for a single recipe in Just

George Shuklin — Thu, 17 Jul 2025 11:19:58 +0000

I found the way, which I think, is the most elegant, to check if environment variable is defined.

foo:
  @test {{ env("FOO") }}

If FOO is not defined, it will fail:

error: Call to function `env` failed: environment variable `FOO` not present
  ——▶ Justfile:2:12
  │
2 │   @test {{ env("FOO") }}
  │            ^^^

Maybe there is a build-in way, but I wasn't able to find it. I want it to be checked for a single recipe, not for the whole file.

from poetry to uv

George Shuklin — Sat, 28 Jun 2025 08:44:58 +0000

I've done my fourth project conversion from Poetry (or a plain pip) to uv.

Results: absolutely zero issues.

Moreover, I have an interesting imrovement. The real reproducible CI image (debian with terraform, just, ansible, sops).

Sizes for tar files for a Docker image:

- poetry (ci image size 264M, build time 2:17-2:26)
+ uv (ci image size 235M, build time 1:30-1:50)

A Python application takes additional ~30MB more in archived state. Why? Because of dependencies. A lot of them. Uv is not small (44MB, but Python one is enormous).

Also, you can see how faster image build become. Most of the build time is Ansible collection installation time (I can't reduce that one), but installation time for all python stack (mostly Ansible and it's dependencies) shrunk from significant to negligible.

Build process spend now more time on apt than on python packages. With poetry and pip, those times were comparable.

I identified two different ways to use uv in the CI image: with uv and without.

If uv is present in the image, you need install it, and you need pyproject.toml and uv.lock files.

If uv is not used, you need to use some other process (usually, the operator) to export dependencies into requirements.txt (with hashes) via uv export. And you can skip copying pyproject.toml file completely.

After trying both ways I more inclined to use with uv (because it's faster, way, way faster). It also removes hassle for creating venv as separate comand. A simple uv sync do the job.

Also, in with uv I can skip python3-pip package, which alleviate some of the size price from adding uv.

Three projects I migrated by hands.

On my fourth project I found even faster way to do it.

uvx migrate-to-uv

It does not exclude CI work (images, etc), but reduce cognitive load on converting pyproject.toml.

... Why not poetry?

Even without 'speed' factor I got two big issues with poetry.

They started well, got into modern distributions (apt-get install python3-poetry), but they broke compatibility in 1.6-2.0, in such a way, that you can't have pyproject.toml been compatible with both. It's moving too fast and breaks too many things to be a packet manager.
I found odd situation that it flips random write bits on installed packets. I build reproducible images, so I have runs, where diffoscope see something odd, like 0754 in one image and 0757 in another. I rune out everything but poetry, and poetry does this. Maybe I should file a bug for this? But I have no definitive proofs (it's probabilistic, random file at random run), and I know how much time I would spend reporting this thing. I already lost few days of my work time nailing problem down. Instead I move from poetry.
There was time when it was possible to use poetry without poetry (poetry export) but they decided it's too easy to use and moved into separate package, deprecating and removing function from the main package. They have reasons. To make things more complex than they should be. I have reasons. To move on.

All this leads to 'should we try uv?', and I tried. Project #1 was simple and migration was trivial. Project #2 was simple and migration was okay (because of CI nuances and internal policies on artifacts). Project #3 (where I tried uv export was okay, but I had to add an additional job to check if uv export is not stale. I didn't liked it. Project #4 was converted in less than hour (including Hadolint nitpicking), and it was straightforward and simple.

And it was reproducible from the first attempt. No more odd caches rm at the end of stage (poetry still leaves some randomness even with --no-cache), just simple uv sync --no-cache.

What I miss is a docker image with uv. Writing 'copy --from' in the Dockerfile is much nicer than my current UV downloading code:

    && bash -c "curl -L https://github.com/astral-sh/uv/releases/download/0.7.16/uv-x86_64-unknown-linux-musl.tar.gz | tar xz --wildcards */uv" \
    && mv uv-x86_64-unknown-linux-musl/uv /usr/local/bin \
    && echo 6538516743f9c33aec8e53398730dcc55c6bbcbe2f660a7757c10d358b85e675  /usr/local/bin/uv | sha256sum -c \

compare to my TF code:

# from hashicorp/terraform:1.12 at 2025-06-22
FROM hashicorp/terraform@sha256:f5ac787eee9d292b6a3b97d40f04019ce08189d356233fc73d5ec7ef8529cce2 as terraform
...
COPY --from=terraform /bin/terraform /usr/local/bin/

(Yep, price for hash pinning is high).