Wesley Dean

DevSecOps Engineer, Author, and Mentor

I’m a technologist, author, and mentor who helps people and organizations move from complexity to clarity. Through consulting, writing, and workshops, I bridge the gap between technical and non-technical teams, translating risk into meaningful decisions and sustainable action. My work centers on leadership, connection, and disciplined execution, drawing on decades of experience to help teams build secure, reliable systems while strengthening trust, alignment, and shared understanding.

Picture of Wesley Dean wearing a black dress shirt

Latest 3 Posts ↓

View all posts →
bash-doxygen, Doxygen documentation for Bash image

bash-doxygen, Doxygen documentation for Bash

6 min read

Last week, I wrote about mktext, a small library that came out of a larger Bash project and became useful enough to deserve its own boundary. bash-doxygen is another tool in that family, although it solves a very different problem: turning carefully documented Bash source into something Doxygen can understand.

I have used Doxygen for years because I like keeping implementation-level contracts close to the code they describe. Bash is awkward territory for that approach. Doxygen understands several programming languages directly, but Bash is not one of the languages for which it can reliably infer functions, parameters, variables, and declarations on its own.

One answer would be to build a Bash parser. That would be a much larger project than the problem justified.

Instead, bash-doxygen takes a narrower approach. It looks for Doxygen-style comment blocks immediately followed by recognizable Bash declarations, then emits a small pseudo-C++ representation that Doxygen can index. Undocumented helpers remain undocumented. Source that does not participate in the documentation contract is left alone.

Read More

mktext, a focused text-substitution library image

mktext, a focused text-substitution library

6 min read

While working on adrctl, I found myself needing a small piece of functionality that was useful there but was not inherently about Architecture Decision Records: substitute caller-supplied values into text.

adrctl needed that capability in two closely related places:

  • users should be able to define patterns for ADR filenames;
  • users should be able to substitute values into ADR body templates.

Both cases involve text containing named tokens that need to be replaced with values. That is also how Nat Pryce’s adr-tools handles ADR templates. Since one of adrctl’s goals is compatibility with adr-tools, existing templates using bare tokens such as TITLE, NUMBER, DATE, and STATUS needed to keep working.

I looked at several libraries and template engines. They were capable tools, but most did considerably more than I wanted. I did not need a programming language hidden inside a template. I needed predictable text substitution with a very small semantic surface.

So, mktext was born.

Read More

ADRCTL, a modernized tool for managing Architecture Decision Records image

ADRCTL, a modernized tool for managing Architecture Decision Records

4 min read

While working on my upcoming book, Getting Started with Architecture Decision Records (ADRs), I demonstrated Nat Pryce’s adr-tools tooling. Nat’s tool is truly excellent and I’ve been using it for years. It’s a Bash shell script that can be used to quickly create and maintain ADRs in a Git repository.

As my needs evolved, I found a little place here and another place there where adr-tools didn’t quite align with my needs. For example, adr-tools has a shell script driver plus a bunch of libraries for individual commands. Don’t get me wrong, I love a modular, extensible approach! On the other hand, it meant having to clone or track a small repository of files, not just a single script.

The filenames adr-tools used for ADRs worked well until I encountered a project whose naming convention conflicted with them.

So, a new tool was born: adrctl!

Read More

39 more posts can be found in the archive.