DEV Community: David Owens

paint pictures like a 5 year old

David Owens — Fri, 24 Oct 2025 23:21:20 +0000

Do you ever find yourself in a design or planning meeting with loads of talking heads, all confidently agreeing on important points, where it's almost like the conclusions are just a matter of fact and should be obvious to anyone?

Yet you leave the meeting feeling unsettled, you sense gaps in the plan filled with vague arm wavey "someone will do something here" or a design that seems to hinge off a "decision engine" the details of which "we'll work out in the implementation."

So you ask around a bit, but no one seems to actually be able to coherently explain what the fuzzy stuff will actually be, what it will do, or even who is doing it.

"I need someone to paint me a picture to understand all this." you say to yourself.

Well guess what, they probably won't.

JFDI yourself, following these 2 rules:

1. Be positively unfussy about it

boxes shouldn't line up neatly
labels should definitely have typos
use crayons if your kids haven't pushed them up their nose

It musn't be good looking

2. Do not leave gaps

Put your best interpretation of what the vague fuzzy stuff is into it. Even though you know you've got it wrong, just put it in.

Then present it back, to everyone.
Could be in the next meeting, an e-mail or paste it in the project Slack channel. Much like a 5 year old with their latest drawing, get it stuck under everyone's nose who you think might be interested and even those who are not.

If you are lucky, human nature will take over, an image that challenges a person's view seems to get much more of an immediate reaction than the written word.

The "someone will do something here" was "my guys will sort this with a perl script in 2 days" to the ops manager, meanwhile the project manager was talking to a recruiter about getting 4 contractors in.

It turns out the "decision engine" was assumed to be a 3 month procurement piece and integration with a SaaS offering to the product manager while one engineer had it down as 14 lines of code in an existing class.

The slightly less confident conversations sparked are great.

But the even better part is, having used crayons, no one will ever trust you with diagramming anything again and immediately someone else will take responsibility to draw your picture up in a "proper tool".

Happy days

listing over to the top right

David Owens — Wed, 24 Sep 2025 20:15:34 +0000

I have no idea why but for some reason I've taken to using Thunderbird as my e-mail client on my "new to me" mac.

When you do a search in Thunderbird for some keyword(s) the results that are returned have limited interactivity, sure there's a nice histogram with the volume of the e-mails found plotted over time, but can you do anything useful like... delete them?

Nope, but fear not, apparently you just need the results in a "list". I thought it already looked "listy", but there's a link in the top right to "show results as list", this allows an even more "listified" view of the results to be rendered in a new tab.

This option evaded me for way too long (and others don't seem super happy with it), but for now I can happily bulk select and trash.

Good night

renaming things is hard also

David Owens — Thu, 05 Jun 2025 17:22:54 +0000

By default docker compose uses the directory name the compose yaml resides in as a project name to prefix to any named volumes.

So given:

home
|_fig-rolls
  |_projects
    |_awesome
      |_docker-compose.yml

With the docker-compose.yml defining a database server I can use where (I hoped) the initial import of a large database dump is persisted between containers:

services:
  mysql:
    image: percona/percona-server:8.4
    container_name: percona-server
    ports:
      - "3306:3306"
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: not_so_awesome
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - percona-data:/var/lib/mysql              # Database data
      - percona-logs:/var/log/mysql              # MySQL logs
      - percona-backups:/backups                 # XtraBackup output
      - ${PWD}/data/not_so_awesome.sql.gz:/docker-entrypoint-initdb.d/not_so_awesome.sql.gz
    restart: unless-stopped

volumes:
  percona-data:
  percona-logs:
  percona-backups:

You end up with:

$ docker volume ls | grep awesome
local     awesome_percona-backups
local     awesome_percona-data
local     awesome_percona-logs

Should be good to docker compose down, all my data is safe in awesome_percona-data.

Of course I only learned this after I renamed my project.

mv /home/fig-rolls/projects/awesome /home/fig-rolls/projects/not_so_awesome

Bring a new container up and of course it's created and mounted an empty not_so_awesome_percona-data volume.

It's obvious really, what-else would Docker use to name the volumes to avoid conflicts with other projects?

Never mind, not that long to reimport from an existing DB dump (used the time to write this.)

It's worth noting you can specify your own volume name which will then not get this project prefix and remain consistent.

And of course the old volumes were actually still there so I could have just jumped through hoops to copy the contents to the newly named volumes (there's weirdly no option to rename.)

Hope this was useful.

Thanks for reading and don't make the same mistake :)

curl, it's got u

David Owens — Wed, 14 May 2025 21:34:43 +0000

I like curl it's available as a command line tool and is pretty ubiquitous across platforms.

This allows me to compose a http request against a test environment, check everything worked as expected and then copy that request from my terminal with the intent of running on production.

Easy - it's all just plain text now, do a find-and-replace on the hostname and it's ready to go!

Here's a hypothetical I've prepared featuring some very important resources I'm going to alter.

curl -X DELETE https://prod.server.net/fig-rolls

However an interface like that should want to authenticate who is conducting such a privileged operation. For this, many still use Basic Auth.

Basic Auth just needs me to base64 encode the username and password and pop it in the Authorization header, so I'll just grab the password out of the secrets management system and do that...

echo 'admin:p4ssw0rd' | base64

(Glad we're spending 5K a year on Vault to protect that /s)

OK, it's ready:
curl -H 'Authorization: YWRtaW46cDRzc3cwcmQK' -X DELETE https://prod.server.net/fig-rolls

To get that run in production it might require me to:

send it to a colleague
commit to a git repository
document in some implementation plan (change management)

You really don't want to put that Authorization header value in any of those.
echo YWRtaW46cDRzc3cwcmQK | base64 --decode

Yeah, no.

But here curl can help you, with -u, you --user you.

curl -u admin -X DELETE https://prod.server.net/fig-rolls

Note there is no secret or encoding of a secret in the command, instead, you get an interactive prompt!

Enter host password for user 'admin':

No longer do you have to instruct someone (or future you) how to encode the password and modify the curl command. Just retrieve it when needed and supply to the prompt, curl takes care of the encoding and addition of the header for you.

OK I'm off to rotate that password above now. Get some special characters in it and make it longerer.

Here we go: .$@[BD:O]_'=M0H;mzkgLOUr1

And yes, here we have another nice benefit of using the interactive prompt. I no longer have to worry about escaping that lot correctly in a shell.

There are other benefits to avoiding secrets being present in any commands you are running in a shell, more knowledgable people feel free to chime in on the comments.

If you want to know more around authentication with curl this is an excellent summary of options available including alternate schemes to Basic Auth and how to authenticate against proxies.
https://everything.curl.dev/http/auth.html

Thanks for reading.