Rob details how to override and remove values in a Docker compose file when using a compose.override.yml or extending a value/service.

To just override it:

- ports: !override
  - "8081:80"

This is necessary, as otherwise if the value is already present in the original, the two settings get merged.

To remove:

- ports: !reset []

Debian and Ubuntu are no longer shipping cron by default, and instead recommending setting up systemd timers. Stephan details how this is done, which requires both a systemd service file, and a systemd timer file.

The service file looks like this:

### Goes into /etc/systemd/system as a file with a .service extension
[Unit]
Description=Description of the service here
Wants=service-name.timer

[Service]
Type=oneshot
ExecStart=/path/to/executable/to/run/here
User=user-to-run-as
Group=group-to-run-as

[Install]
WantedBy=multi-user.target

You then create a timer, which is a systemd service defining a Timer section with an interval specified:

### Goes into /etc/systemd/system as a file with a .timer extension

[Unit]
Description=Executes every minute
Requires=service-name.service

[Timer]
Unit=service-name.service
OnCalendar=minutely

[Install]
WatnedBy=multi-user.target

The OnCalendar property can use "natural language" shortcuts like "minutely" or "hourly", or you can define date/time-based interval such as *-*-* *:*:00.

Once done, you need to start the service and enable the timer (usually as root):

systemctl start service-name.service
systemctl enable service-name.timer

and trigger it manually any time using:

systemctl start service-name.service

Rob Allen details how the exec form of a Docker CMD is the better form to use. The reason the string form invokes bash first, and thus bash gets PID 1, which is what Docker will terminate when the container is terminated. The problem is that bash doesn't then send a termination signal to the actual process invoked, forcing the Docker host to wait 10 seconds before force killing all processes in the container.

There is an adage attributed to G.K. Chesterton called "Chesterton's Fence" that can be abbreviated to this:

Do not remove a fence until you know why it was up in the first place.

I've read this article after a number of recent articles decrying the idea of "Founder's Mode" and other crappy entrepreneurial beliefs, and it struck a note with me. So many "disruptors" do not stop to understand why things operate as they currently do: what does having a taxi license solve for the community? what do environmental regulations solve for ecosystems? what additional regulations do hotels and other commercial lodgings need to abide by to protect consumers and employees? etc.

gron is a tool for working with JSON. It chunks things into key-value pairs where the key is a dot-separated hierarchy. This allows you then to use grep or ack to search for strings of interest.

It can also reassemble these back into JSON. This can be useful for adding or removing portions of a JSON structure. It becomes really interesting then when you pair it with jq in order to retrieve data back out.

As an example, I can get the list of development requirements from a composer.json with the following:

gron composer.json | ack "require-dev" | gron -u | jq '."require-dev" | keys[]'

(They'll still be in quotes, but that's easier to deal with than JSON keys!)

Quick select mode in Wezterm allows you to identify patterns in the current visible screen; Wezterm then highlights each and provides a key to each allowing you to copy and/or paste the associated value. Activate it with Ctrl-Shift-Space.

As examples:

• It matches sha1 and md5 values. Use these to match a git ref in a log so you can then inspect it.
• It matches Docker container identifiers; use these to match a container identifier so you can run a command in it or copy a file from or to it.
• It matches URLs; use it to identify a URL to pass to HTTPie.
• It matches paths; use it to match a path to perform a file operation on.