DEV Community: Nick Ciolpan

Building a Docker debug TUI in Rust with output-aware follow-ups

Nick Ciolpan — Sat, 09 May 2026 15:24:41 +0000

Every time I debug a container I run the same loop:

docker ps -a                       # find the thing
# squint, copy a name with the mouse
docker logs casely-postgres-1
docker inspect casely-postgres-1
docker exec -it casely-postgres-1 sh

The container name doesn't change between those commands. The shell doesn't help me; I copy and paste — sometimes typoing a hash prefix.

So I built dux — a single Rust binary with a TUI (ratatui) and a browser UI (axum), 105 curated docker commands, and after every run it parses the output and prefills the next command's args.

brew install nickciolpan/tap/dux
dux           # terminal UI
dux serve     # http://127.0.0.1:7878/dux

Source: github.com/nickciolpan/dux. MIT.

The rest of this post walks through the two ideas that make it work.

Idea 1 — typed placeholders

Each command in the catalog is a const struct:

pub struct Cmd {
    pub id:         &'static str,
    pub name:       &'static str,
    pub desc:       &'static str,
    pub long_desc:  &'static str,
    pub template:   &'static str,            // "docker logs {container}"
    pub category:   &'static str,
    pub produces:   Produces,                // what the stdout lists
    pub follow_ups: &'static [&'static str], // ids
}

template uses {name} placeholders. Each placeholder maps to an ArgKind:

pub enum ArgKind { Free, Container, Image, Network, Volume, Service }

pub fn arg_kind(name: &str) -> ArgKind {
    match name {
        "container"        => ArgKind::Container,
        "image" | "source" => ArgKind::Image,
        "network"          => ArgKind::Network,
        "volume"           => ArgKind::Volume,
        "service"          => ArgKind::Service,
        _                  => ArgKind::Free,
    }
}

That's the entire kind system. Five real kinds plus Free for raw text (file paths, env values, port numbers, etc.).

produces says what the command's stdout contains:

pub enum Produces { None, Containers, Images, Networks, Volumes, Services }

So docker ps is Produces::Containers, docker images is Produces::Images. Most commands are Produces::None.

Two annotations. Everything else falls out.

Idea 2 — parse stdout into typed candidates

After every run, extract::extract(produces, stdout) returns a typed bag:

pub struct Candidates {
    pub containers: Vec<String>,
    pub images:     Vec<String>,
    pub networks:   Vec<String>,
    pub volumes:    Vec<String>,
    pub services:   Vec<String>,
}

For docker ps, the parser is small and fault-tolerant — skip the header row, then for each line take the first whitespace token (the ID) and the last (the NAME):

fn parse_containers(s: &str, c: &mut Candidates) {
    for line in data_lines(s) {
        if line.contains('\t') {
            // ps with --format 'table {{.ID}}\t{{.Names}}\t...'
            let parts: Vec<&str> = line.split('\t').map(str::trim).collect();
            if let Some(id)   = parts.first() { dedup_push(&mut c.containers, id.to_string()); }
            if let Some(name) = parts.get(1)  { dedup_push(&mut c.containers, name.to_string()); }
            continue;
        }
        let toks: Vec<&str> = line.split_whitespace().collect();
        if toks.is_empty() { continue; }
        dedup_push(&mut c.containers, toks[0].to_string());
        let last = toks[toks.len() - 1];
        for n in last.split(',') { dedup_push(&mut c.containers, n.trim().to_string()); }
    }
}

docker images parses REPOSITORY, TAG, and IMAGE ID columns into repo:tag and the bare ID. docker network ls and docker volume ls are even simpler. The whole module is ~150 lines and unit-tested.

The TUI keeps the most recent Candidates in app state. When a follow-up command needs {container}, it looks up arg_kind for that placeholder and pulls candidates from the matching bucket. First candidate auto-fills; ↑ / ↓ cycle.

The web UI does the same thing client-side: each POST /api/run/:id returns candidates alongside stdout, and the form renders a <datalist> per typed arg.

Search across the explainers

Every command also has a long_desc — one or two sentences describing what it does and the non-obvious flags. The catalog search filters on id, name, desc, long_desc, template, and category, all live as you type.

The third filter in that clip — rotation — only matches because the kill -s SIGNAL command's explainer mentions log rotation. The explainers aren't decoration; they're a searchable index.

Two surfaces from one catalog

main.rs is just clap subcommands:

match cli.command.unwrap_or(Cmd::Tui) {
    Cmd::Tui => tui::run()?,
    Cmd::Serve { addr, route } => {
        let rt = tokio::runtime::Runtime::new()?;
        rt.block_on(web::serve(addr.parse()?, route))?;
    }
    Cmd::Catalog => println!("{}", serde_json::to_string_pretty(&CATALOG)?),
}

Both surfaces import the same catalog::CATALOG and call the same runner::run and extract::extract. There's no separate "model layer." The TUI is ratatui::Frame widgets; the web UI is axum::Router returning Json<CmdView> (where CmdView: From<&'static Cmd>). The HTML page is a single file embedded with include_str!("../assets/index.html") — no build step, no bundler.

This means adding a command is one place: append to CATALOG. Both UIs pick it up. Adding a new arg kind (e.g. service for compose) was 4 lines in catalog.rs and 3 lines in extract.rs.

What it isn't

Not a Docker rewrite. Every command is sh -c "docker …" shelled out.
Not a dashboard. There's no live state polling; the model is run-on-demand, like the CLI itself.
Not a daemon. dux serve is a thin HTTP-to-shell layer for your local Docker socket, intended for localhost use (or behind your VPN). Don't expose it raw to the internet.

That's also why it stays small — the binary is ~2.4 MB release-stripped and starts in ~50 ms.

Try it

brew install nickciolpan/tap/dux
dux                    # TUI
dux serve              # http://127.0.0.1:7878/dux
dux catalog | jq .     # full command catalog as JSON

Or build from source if you'd rather:

git clone https://github.com/nickciolpan/dux.git
cd dux
cargo install --path .

If you make it interesting, the catalog is data — open a PR with a new Cmd { … } entry and your follow-up suggestions, and you've extended both UIs at once.

Repo: github.com/nickciolpan/dux
Site: nickciolpan.github.io/dux

How to Secure Claude CLI When It Runs Inside Your Software (don't ask)

Nick Ciolpan — Thu, 16 Apr 2026 08:14:42 +0000

If your application triggers Claude CLI server-side based on user input, you have a prompt injection surface. User types freeform text, your app wraps it in a prompt, Claude processes it. Without guardrails, that user could attempt to make Claude leak context, produce malicious output, or — if tools are enabled — interact with the host system.

Five layers, stacked. None sufficient alone.

Layer 1: Text-Only Mode

claude --print

--print disables interactive tool use in normal operation. Claude receives text via stdin, returns text via stdout. No file reads, no bash, no writes.

Caveat: This is a behavioral constraint, not a formal security boundary. It depends on CLI implementation details and should not be your only control.

Layer 2: Strip Capabilities

claude --print \
  --bare \
  --disallowedTools "Bash,Edit,Write,Read,Glob,Grep,Agent,NotebookEdit"

--bare disables hooks, LSP, plugin sync, auto-discovery of project files (CLAUDE.md), and keychain reads. Reduces context available to the model — but does not guarantee zero leakage. Environment variables and OS-level information may still be accessible at the process level.
--disallowedTools explicitly denies every tool by name. Defense in depth — if --print behavior changes in a future version, tools remain blocked.

Layer 3: Process Isolation

const child = spawn("claude", ["--print", "--bare", "--disallowedTools", "..."], {
  cwd: os.tmpdir(),
  timeout: 300000,
});

cwd: /tmp means the process starts in a directory with nothing interesting. This is not a filesystem sandbox — the process can still access absolute paths. It reduces incidental exposure, not hard access.

For actual isolation, run the process inside a container with restricted filesystem mounts, no network access, a non-root user, and resource limits (memory, CPU). The cwd trick is a soft boundary, not a security boundary.

Layer 4: Prompt Validation

function validatePrompt(prompt) {
  // Must contain system marker (user input alone can't form a valid prompt)
  if (!prompt.includes("YourSystemMarker")) {
    return "Prompt must originate from the application";
  }

  // Reduce obvious attack patterns
  const forbidden = [
    /```
{% endraw %}
(?:bash|sh|shell|zsh)\n/i,
    /\bexec\s*\(/i,
    /\bprocess\.env/i,
    /\bchild_process/i,
    /\bfs\.\w+/i,
    /rm\s+-rf/i,
    /sudo\s/i,
  ];

  for (const pattern of forbidden) {
    if (pattern.test(prompt)) return {% raw %}`Blocked: ${pattern}`{% endraw %};
  }

  // Must request structured output (app controls format, not user)
  if (!prompt.includes("===OUTPUT_START===")) {
    return "Prompt must request delimited output";
  }

  return null;
}
{% raw %}

The system marker and output delimiters ensure the app assembled the prompt — raw user input can't pass validation alone.

Important limitation: Prompt injection is semantic, not syntactic. A user doesn't need exec() or rm -rf to manipulate model behavior. They can write "ignore previous instructions" or "reveal the system prompt" and no regex catches that. Pattern matching reduces surface area for obvious attacks. It does not prevent prompt injection.

Layer 5: Output Containment

This is the most important layer. Never execute Claude's output. Treat it as untrusted text.


javascript
const match = output.match(/===OUTPUT_START===([\s\S]*?)===OUTPUT_END===/);

const targetDir = `outputs/${sessionId}/`;
fs.writeFileSync(path.join(targetDir, "result.md"), match[1]);

Write only to an isolated output directory — never source code, config, or system files
Write only inert file types (markdown, static HTML) — never executable code
New directory per operation — previous outputs are immutable

The real danger from LLM output is indirect: your system does something dangerous with it. If the output is never executed, evaluated, or passed to a shell, the model's text is inert regardless of what it says.

Combined


plaintext
User input (freeform text)
  ↓
App assembles prompt (system context + delimiters + user text)
  ↓
[Layer 4] Validate prompt (origin, patterns, format)
  ↓
[Layer 1-3] claude --print --bare --disallowedTools "..." --cwd /tmp
  ↓
[Layer 5] Parse delimited output → write to isolated directory

What this achieves:

User can't control prompt structure (app assembles it)
Obvious injection patterns are rejected (regex filter)
Tools are disabled at CLI level (behavioral + explicit deny)
Host context is reduced (bare mode, /tmp cwd)
Output is treated as untrusted text (never executed)

What this does not achieve:

Prevention of semantic prompt injection ("ignore instructions")
Guaranteed zero context leakage (env vars, process info)
Filesystem sandboxing (cwd is not chroot)

API vs CLI

When calling the Anthropic API directly, layers 1-3 don't apply — there's no CLI process. Layers 4 and 5 still work identically. The API has no filesystem access by default, but injection risk remains: the model can still be manipulated to leak data you included in the prompt or produce output that influences downstream systems.

Starting Point, Not Endpoint

With all five layers applied, Claude is rendered effectively harmless — it can't use tools, can't see files, can't execute commands, and its output goes nowhere dangerous. This is the correct starting point. Strip everything, verify it's inert, then selectively grant back capability and access as your use case requires — with each addition evaluated as a new attack surface.

Your Dockerfile Scanner Should Break the Build

Nick Ciolpan — Wed, 25 Mar 2026 07:33:28 +0000

The problem

Last month I shipped docker-scan-lite. It scanned. It warned.

Then everyone kept shipping broken images anyway.

Because it always exited 0. Green pipeline. Every time. Didn't matter if you had USER root with a hardcoded AWS key. CI said ✅. You shipped it.

Warnings without consequences are just noise.

Now it breaks the build

docker-scan-lite -f Dockerfile --exit-code high

One flag. Pipeline stops when it matters.

GitHub Action

No install step. No binary downloads:

- name: Scan Dockerfile
  uses: nickciolpan/docker-scan-lite@v1
  with:
    dockerfile: Dockerfile
    fail-on: high

Hardcoded secret? Blocked.
Running as root? Blocked.
Sensitive env var in plaintext? Blocked.

Everything else — warnings. You see them, you decide.

New checks

Missing HEALTHCHECK:

⚠️ [INFO] No HEALTHCHECK instruction found

Your orchestrator is flying blind without it.

No USER instruction:

⚠️ [MEDIUM] No USER instruction in final stage. Container will run as root by default

Not USER root — no USER at all. The silent default nobody thinks about.

Multi-stage awareness:

FROM golang:1.21 AS builder    # issues here matter less
RUN go build -o /app

FROM alpine:3.18               # this is what ships
COPY --from=builder /app /app
USER appuser

It now knows the difference between a build stage and what actually runs in production.

Less noise

Before, every URL got flagged as a "database connection string":

⚠️ database_url: https://example.com/install.sh

Fixed. Only actual DB protocols now — postgres://, mysql://, mongodb://.

FROM scratch no longer gets flagged as "using latest tag". It's not an image.

Want only the critical stuff?

docker-scan-lite -f Dockerfile --severity high

SARIF output

For GitHub's Security tab:

- name: Scan
  uses: nickciolpan/docker-scan-lite@v1
  with:
    dockerfile: Dockerfile
    format: sarif
    fail-on: ''

- name: Upload SARIF
  uses: github/codeql-action/upload-sarif@v3
  if: always()
  with:
    sarif_file: scan-results.sarif

Dockerfile issues show up next to your CodeQL findings.

Install

brew upgrade nickciolpan/tap/docker-scan-lite
# or
go install github.com/nickciolpan/docker-scan-lite@latest

Docs: nickciolpan.github.io/docker-scan-lite
GitHub: github.com/nickciolpan/docker-scan-lite

What's the worst thing your CI let through?

I built a terminal-native Little Snitch alternative for macOS

Nick Ciolpan — Tue, 24 Mar 2026 11:49:08 +0000

I wanted to know what my Mac was doing behind my back.

Every app phones home. Electron apps ping telemetry endpoints. Browsers hit trackers. Even system processes make connections you never asked for. Little Snitch shows you all of this beautifully — it's a proper, polished product and well worth the money.

This is not a replacement for Little Snitch. This is what happens when you're curious about network monitoring and want to see how far you can get with Go, lsof, and pfctl in a terminal. Think of it as a learning project that accidentally became useful.

CLI Snitch watches every outbound TCP and UDP connection, prompts you to allow or deny, and enforces your decisions with real macOS firewall rules — all from the terminal.

What it looks like

$ sudo cli-snitch watch

🚨 New Outbound Connection Detected
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  📱 Application: Electron Helper
  🌐 Destination: telemetry.example.com:443
  🔌 Protocol:    TCP
  🏷️  Host Info:   Amazon Web Services (AWS)

? What would you like to do?
  ✅ Allow Once
  🔁 Allow Always
  ❌ Deny Once
> 🚫 Deny Always

❌ Electron Helper DENIED -> telemetry.example.com:443
🔥 Firewall rule: block out proto tcp from any to telemetry.example.com port 443
🛡️ Firewall rule applied

That last line is real. It's not a log message — it's an actual pfctl rule injected into the macOS packet filter. The connection is blocked at the kernel level.

How it works

The architecture is straightforward:

Detect — lsof -i tcp -i udp -n every 2 seconds (adaptive intervals)
Match — Check new connections against saved rules (case-insensitive, supports glob patterns)
Prompt — If no rule matches, ask the user via an interactive terminal prompt
Enforce — Deny decisions create pfctl anchor rules that survive the session
Remember — Decisions are saved as JSON rules and logged to a JSONL history file

The interesting engineering problems were:

Prompt serialization

Multiple connections can arrive within the same 2-second scan. If two prompts hit stdin simultaneously, everything breaks. I solved this with a buffered channel queue:

type promptRequest struct {
    conn     *monitor.Connection
    resultCh chan promptResult
}

func (cp *ConnectionPrompter) QueuePrompt(conn *Connection) (*UserDecision, error) {
    req := &promptRequest{
        conn:     conn,
        resultCh: make(chan promptResult, 1),
    }
    cp.promptQueue <- req
    res := <-req.resultCh
    return res.decision, res.err
}

A single goroutine reads from the queue and calls the survey prompt — one at a time, no collisions.

pfctl input sanitization

When a user denies a connection, the host and port values end up in a pfctl command. If I naively concatenated those strings, a malformed hostname could inject commands. Every value is validated against regex before it touches pfctl:

var hostPattern = regexp.MustCompile(`^[a-zA-Z0-9._:\-]+$`)
var portPattern = regexp.MustCompile(`^[0-9]+$`)

Connection deduplication

lsof reports all active connections every scan, not just new ones. The monitor maintains a map of seen connections plus a TTL-based "recent cache" — so connections that get cleaned up from the main map but reappear within 5 minutes don't re-trigger prompts.

What you get

14 commands:

watch              Real-time monitoring (the main event)
list-rules         See all your allow/deny rules
edit-rule          Modify a rule inline
import-rules       Load rules from JSON
export-rules       Back up rules to JSON
history            View connection log with filters
firewall-status    Check pfctl integration
list-firewall      Show active blocking rules
clear-firewall     Remove all pfctl rules
firewall-cleanup   Remove expired temp rules
firewall-monitor   Live firewall status
system-status      Full diagnostics
daemon install     Set up as a launchd service
daemon start/stop  Control the background service

Some features I'm particularly happy with:

Wildcard rules — *.analytics.com blocks all analytics subdomains
DNS reverse lookup with caching — so you see hostnames, not just IPs
Connection history — every decision logged to JSONL, filterable by process or action
Daemon mode — sudo cli-snitch daemon install creates a launchd plist for background monitoring
Rule scoping — block a specific connection, all connections to a host, all connections on a port, or everything from a process

Install

brew tap nickciolpan/tap
brew install cli-snitch
sudo cli-snitch watch

Or build from source:

git clone https://github.com/nickciolpan/snitcher
cd snitcher
go build -o cli-snitch ./cmd/cli-snitch
sudo ./cli-snitch watch

What it can't do

Being honest about the limitations:

No per-process blocking in pfctl — macOS packet filter doesn't have a concept of process ownership. If two apps connect to the same host:port, a deny rule blocks both. True per-process filtering needs Apple's Network Extension framework (Swift, not Go).
No bandwidth tracking — would need BPF packet capture.
lsof truncates process names — Google Chrome Helper becomes Google, Slack becomes Slack\x20. Works fine once you know the quirk.

What I learned

lsof is surprisingly good for this use case. It's fast, available everywhere, and the output is parseable. The main gotcha is IPv6 bracket notation and process name encoding.
pfctl anchors are the right abstraction. By isolating all CLI Snitch rules in a named anchor, there's zero risk of clobbering system firewall rules. Cleanup is just "reload an empty anchor file."
Interactive CLI tools need careful goroutine design. The prompt queue pattern — buffered channel + single-reader goroutine — is something I'll reuse in every interactive CLI from now on.

The source is at github.com/nickciolpan/snitcher and the docs are at cli-snitch.ciolpan.com. MIT licensed.

If you've ever wondered what your Mac is doing when you're not looking, give it a try. You might be surprised.

Yes, this was written with the help of an LLM. The code too. Are we still pretending that's not how things get built in 2026? Claude wrote most of the implementation, I steered, tested, broke things, and made the decisions. The architecture is real, the bugs were real, and the pfctl rules definitely blocked my Chrome tabs for real. Tools are tools — what matters is whether the thing works. It does.

Stop shipping insecure file permissions

Nick Ciolpan — Mon, 23 Jun 2025 10:55:09 +0000

We set up file permissions in a hurry:

chmod 777 (it just works)
chmod 666 (for testing)
No SUID audit (it's just one binary)
Open temp files (gotta ship)

We hear warnings but keep driving.

DO:

curl -L https://github.com/nickciolpan/permcheck/releases/latest/download/permcheck-linux-amd64 -o permcheck
chmod +x permcheck
sudo mv permcheck /usr/local/bin/

Catches:

World-writable files
SUID/SGID binaries
Insecure temp files
Overly permissive directories

Real output:

╔══════════════════════════════════════════════════════════════════╗
║                    🔒 SECURITY SCAN INITIATED                   ║
╚══════════════════════════════════════════════════════════════════╝

🌍 WORLD-WRITABLE FILES (2 found):
  ⚠️  /home/user/project/config.txt (0666)
      💡 World-writable means ANY user can modify this file!
      💡 Consider: chmod 644 /home/user/project/config.txt

Setup (30 seconds)

Add to CI:

- name: Security Scan
  run: permcheck scan

30 seconds to install. Catches stupid mistakes before production.

Best Practices

Executables: 755 (rwxr-xr-x)
Configuration: 644 (rw-r--r--)
Sensitive data: 600 (rw-------)
Directories: 755 (rwxr-xr-x)

Never use:

777 (rwxrwxrwx)
666 (rw-rw-rw-)
Any world-writable permissions

GitHub: https://github.com/nickciolpan/permcheck

What's your worst file permission mistake?

Stop Shipping Broken Docker Images

Nick Ciolpan — Wed, 11 Jun 2025 12:43:51 +0000

docker-scan-lite after seeing too many prod incidents from:

FROM ubuntu:latest
USER root
Hardcoded API keys
No version pinning

DON'T

Last week: seen container compromised because someone deployed with root user + hardcoded API key.

This happens. We write Dockerfiles in a hurry:

FROM ubuntu:latest (no time for versions)
USER root (it just works)
Hardcoded secrets (just for testing)
No pinning (build's failing, gotta ship)

we hear warnings but keep driving.

DO

go install github.com/nickciolpan/docker-scan-lite@latest
docker-scan-lite scan Dockerfile

Catches:

Vulnerable base images
Hardcoded secrets
Root user configs
Insecure commands
Unpinned packages

Real output:

🐳 Docker Scan Lite Results
📊 Summary: 3 issues found
🔒 Security Issues
  ⚠️ [HIGH] Container running as root user (line 15)
  ⚠️ [MEDIUM] Using 'latest' tag not recommended (line 1)
  ⚠️ [LOW] Package installation without version pinning (line 8)

Setup (30 seconds)

Add to CI:

- name: Scan Dockerfile
  run: docker-scan-lite scan Dockerfile

30 seconds to install. Catches stupid mistakes before production.

GitHub: https://github.com/nickciolpan/docker-scan-lite

What's your worst Docker security mistake?

Docker #DevOps #Security

TIL How to Batch Compress PDF Files Using Ghostscript

Nick Ciolpan — Sun, 06 Oct 2024 08:31:46 +0000

brew install ghostscript

#!/bin/bash
[ $# -lt 3 ] && { echo "Usage: $0 /input_dir /output_dir /quality"; exit 1; }
input_dir="$1"; output_dir="$2"; quality="$3"
mkdir -p "$output_dir"
for file in "$input_dir"/*.pdf; do
  base=$(basename "$file" .pdf)
  gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS="$quality" -dNOPAUSE -dQUIET -dBATCH -sOutputFile="$output_dir/${base}_compressed.pdf" "$file"
done

./compress_pdfs.sh /path/to/input /path/to/output /quality_setting

Quality options: /screen, /ebook, /printer, /prepress.

Say goodbye to online pdf converters.

Originally posted on: https://graffino.com/til/til-how-to-batch-compress-pdf-files-using-ghostscript

TIL: How to Quickly Check Which AWS Regions Support SES Using a Bash Script

Nick Ciolpan — Sun, 06 Oct 2024 05:53:00 +0000

Although it has improved lately for some services, AWS is still notoriously unfriendly when it comes to checking which services are activated and running across different regions. Here's a script you can run in the console to quickly see which regions have SES (Simple Email Service) available:

#!/bin/bash
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
    echo "Checking SES in region: $region"
    if output=$(aws ses get-send-quota --region $region 2>&1); then
        echo "SES is active in region: $region"
        echo "$output"
    else
        echo "SES is not available in region: $region"
    fi
    echo "---------------------------------------"
done

This script loops through all AWS regions and checks if SES is running in each one, giving you a quick and easy overview of SES availability.

The output:

`
Checking SES in region: us-east-1
SES is active in region: us-east-1
{
"Max24HourSend": 50000.0,
"MaxSendRate": 14.0,
"SentLast24Hours": 0.0

}

Checking SES in region: us-west-1

SES is not available in region: us-west-1

Checking SES in region: eu-west-1
SES is active in region: eu-west-1
{
"Max24HourSend": 50000.0,
"MaxSendRate": 10.0,
"SentLast24Hours": 0.0

}

First appeared at: https://graffino.com/til/til-how-to-quickly-check-which-aws-regions-support-ses-using-a-bash-script

Orthogonality in Programming: Why Elm Gets It Right

Nick Ciolpan — Wed, 11 Sep 2024 07:41:41 +0000

The debate over the perfect language syntax is far from over—in fact, it’s constantly diverging. And I believe the mainstream is heading in the wrong direction.

When evaluating a language, we typically look at factors like expressiveness, readability, abstraction, and consistency—familiar metrics.

JavaScript, on its own, isn’t perfect, but it’s not terrible either.

The real issue isn’t just JavaScript—it’s the language of the web. To deliver a complete web experience, you need to juggle multiple languages and syntaxes and up with a chimera. Modern tooling leads to something like this (React devs will know this well):

<div 
    className="..." 
    style={{...}} 
    onClick={()=>...} 
    data-testid="...">
    {....}
</div>

In order to cover all the constructs that can be expressed in a web interface, the language expands its domain to cover all possible meaning and interaction. This is the equivalent of writing 100 branching if-else statements to account for every condition.

But if you’ve grown up with this syntax, you’re likely blind to it—and that’s completely normal.

What’s missing is orthogonality— being the ability to express a large set of concepts with a small set of constructs.

Now, Elm gets it:

div
    [ class ...
    , style [color: ...] 
    , onClick ...
    , attribute "data-testid" ...
    ]
    [ text ... ]

In Elm, everything revolves around functions and lists—lists of values, lists of functions, and functions that operate on lists.

Why is this important? Combined with type safety, it provides both predictability AND flexibility—two concepts that may seem contradictory to the uninitiated.

Beyond workarounds: DCI offers a genuine take on traditional OOP design patterns

Nick Ciolpan — Wed, 15 Nov 2023 08:50:19 +0000

Object-Oriented Programming (OOP) design patterns are established solutions to common problems in software design. However, upon closer inspection, one might consider them workarounds operating within the constraints of the traditional OOP paradigm. This paradigm is, in fact, class-oriented programming with a capital 'C'. It focuses on objects as entities that combine state and behavior, reasoning about the "real world" as categories and hierarchies, rather than as networks of collaborating objects, which was Alan Kay's original vision.

This brief compilation serves as a reference and a slightly more extended response to the word count-restricted comment on this LinkedIn article: https://www.linkedin.com/advice/3/how-can-you-design-structured-programs-easy-read-maintain-hhkcc?trk=cah2

DCI (Data-Context-Interaction) aims to address some of the limitations of OOP by introducing a paradigm where the system's data and its behavior are treated as separate concerns. Here's how DCI can be seen as a radical solution that potentially eliminates the need for certain OOP design patterns:

Role Separation: In traditional OOP, an object's role is often inferred from its class. DCI, however, makes roles explicit. Roles in DCI are about what an object does in a given context, not what it is forever bound to by its class. This can reduce the need for patterns that deal with behavior variations, like Strategy or State patterns.

Behavior Encapsulation: OOP typically encapsulates behavior within objects. DCI encapsulates behavior within contexts, making the code more readable and aligned with the actual use cases, which can diminish the reliance on patterns like Command or Template Method that are used to manage behaviors.

Contexts Over Classes: Many OOP design patterns (e.g., Observer, Mediator) are used to handle interactions between classes. DCI promotes the use of contexts to manage interactions, which can simplify complex communication patterns and reduce the need for intermediary objects or class hierarchies.

Interactions as First-Class Citizens: In DCI, interactions are not second-class citizens that just emerge from objects calling each other's methods. They are first-class citizens that can be directly modeled and manipulated, which could negate the need for patterns that orchestrate interactions like Chain of Responsibility or Mediator.

Object Adaptation: DCI allows objects to take on different roles in different contexts, which can alleviate the need for patterns like Adapter or Decorator that are traditionally used to modify an object's interface or add new responsibilities.

Human Mental Models: DCI is designed to reflect human mental models more accurately than traditional OOP. It models the system based on real-world scenarios, potentially reducing the need for patterns that exist primarily to bridge the gap between human thinking and system design, such as Facade or Builder.

DCI proposes a radical shift in thinking about object interactions, aiming to make the codebase more intuitive and better aligned with the problem domain. However, it's important to understand both the context in which design patterns are used and the context in which DCI can be applied, to make the best use of each according to the needs of the project.

Beyond the Hype: Rethinking Decoupled Architecture and the Pursuit of Modern Frontends

Nick Ciolpan — Wed, 04 Oct 2023 09:28:03 +0000

Decoupled architecture used to be the magic bullet when one generator (data source) catered to multiple consumers (multiple frontends, third-party services). But that narrative has shifted. Nowadays, it's often seen as the key to leveraging React.

Chasing after the most popular frameworks can sometimes lead us astray. While it might look appealing on job listings, introducing a new layer, like a “beautiful” RESTful JSON API, comes with its own set of complications. Think JWT authentication, state management, data serialization, and API versioning. Remember, these are strategies to mitigate problems, not features!

I recall a conversation where I cautioned against mindlessly using "react-create-new-app" for every new project. The retort was, "What's the alternative? It was worse before with templates." We mustn't be trapped by the past. It's crucial to keep an eye on the horizon.

Single Page Applications (SPAs) have indeed revolutionized front-end development, introducing many best practices. Let's delve into a few:

Isomorphism: A JavaScript boon. First, JavaScript runs on the server, then again on the client. Frameworks like meteor.js elevate this by offering data on-the-fly through live databases.
Server-driven UI: Take Livewire or Blazor as examples. As Alan Kay once said, "For all it matters, for the user, the interface is the end product." Such tools allow developers to craft end-to-end apps in a contemporary fashion.
Adapters and Glue: Consider Interia.js or Hilla for Java. The latter seamlessly translates Java types and resources into TypeScript types. It even supports calling Java services from a React component without any extra setup.

In sum, while JSP pages and old index.php files might have their detractors, there are innovative solutions available that don't necessitate maintaining an extra layer just for the pleasure of using React.

What about future mobile app needs? Unless it's specified by the client, are you factoring in the costs of your personal assumptions?

Let's conclude with a parable: A young boy asked his mother why she chopped off the ends of the corn before boiling it. She didn’t know, saying it was a method learned from her own mother. The grandmother similarly pointed to her mother. The great-grandmother, when questioned, revealed she had a small pot, necessitating the corn’s truncation. Three generations persisted with an unnecessary practice, oblivious to its origins.

This story underlines a key point: don't blindly follow industry trends. Understand the compromises and context behind every choice. Before jumping into modern frontend, question if there's a smarter approach that sidesteps the pitfalls, putting you firmly in the driver's seat of solution architecture.

Enhancing Models with Meta Attributes: A Dive into Business Logic Beyond the Database

Nick Ciolpan — Wed, 04 Oct 2023 09:26:12 +0000

A perfect example of this complexity is when certain fields in your models require additional metadata - a set of attributes that aren't stored directly in the database but are instead derived or computed from existing fields. This metadata often encapsulates business rules and logic that can be tailored to individual model instances.

Web applications, especially those built on top of relational databases, often lean heavily on their models to define and structure their data. These models are typically a direct reflection of the database tables they represent. However, in the complex world of modern web development, sometimes the data in the database isn't enough.

Carrying Business Logic with Meta Attributes

Consider an eCommerce application where each product has a price. This price, though a singular value in the database, might carry with it a wealth of additional information such as currency, tax percentage, discount applicability, and more. Rather than altering the database schema to accommodate these attributes, they can be computed on the fly based on business rules, thus preserving database simplicity while providing enriched data to the application.

Let's dive into this with a concrete example.

The `HasMetaAttributes` Trait

This PHP trait, designed to be used within a Laravel application, empowers any Eloquent model to handle meta attributes seamlessly:

namespace App\Traits;

use Illuminate\Support\Str;

trait HasMetaAttributes
{
    protected static $globalWithMeta = false;
    protected $instanceWithMeta = null;

    public static function toggleMeta(bool $withMeta = true)
    {
        static::$globalWithMeta = $withMeta;
    }

    public function withMeta(bool $withMeta = true)
    {
        $this->instanceWithMeta = $withMeta;
        return $this;
    }

    public function getAttribute($key)
    {
        $value = parent::getAttribute($key);
        $withMeta = $this->instanceWithMeta !== null ? $this->instanceWithMeta : static::$globalWithMeta;

        if ($withMeta && isset($this->meta[$key])) {
            $meta = $this->meta[$key];
            return [
                'value' => $value,
                'meta' => $meta,
            ];
        }

        return $value;
    }

    public function toArray()
    {
        $attributes = parent::toArray();
        $withMeta = $this->instanceWithMeta !== null ? $this->instanceWithMeta : static::$globalWithMeta;

        if ($withMeta) {
            foreach ($this->meta as $key => $metaData) {
                if (array_key_exists($key, $attributes)) {
                    $attributes['meta'][] = [
                        $key => $metaData,
                    ];
                }
            }
        }

        return $attributes;
    }
}

When used in a model, the trait offers the capability to toggle the meta attributes on or off, either globally across all model instances or on a per-instance basis.

Application in an Eloquent Model

For the sake of illustration, we will use a Product model:

namespace App\\Models;

use Illuminate\\Database\\Eloquent\\Model;
use App\\Traits\\HasMetaAttributes;

class Product extends Model
{
    use HasMetaAttributes;

    protected $fillable = ['name', 'price'];
    protected $meta = [
        'price' => [
            'currency' => 'USD',
            'tax' => '10%'
        ]
    ];
}

>>> use App\Models\Product;

>>> Product::toggleMeta(true);

>>> $product = Product::find(1);
>>> echo $product->price;

Output

[
    "value" => 100.00,
    "meta" => [
        "currency" => "USD",
        "tax" => "10%"
    ]
]

Toggle Off

>>> Product::toggleMeta(false);

>>> $product = Product::find(1);
>>> echo $product->price;

Output

100.00

Architectural Considerations and Alternative Approaches

The approach detailed above certainly offers a layer of dynamism to your models. However, depending on the application's complexity and performance needs, some might find alternative designs more fitting:

Database Views: Instead of computing meta attributes in the application, create a database view that joins and aggregates data as required. This will offload computational tasks to the database but might make the application logic less clear.
Service Layer: Rather than enriching models directly, introduce a service layer that fetches model data and then augments it with additional attributes. This separates business logic from data representation and is often a favored approach in complex applications.
Decorator Pattern: Use a decorator to wrap around the model, adding additional behavior or data without modifying the model's structure.
Event Listeners: In scenarios where computed attributes don't change frequently, compute them once and store the results. Use event listeners to re-compute whenever the underlying data changes.

Conclusion

Models, while traditionally reflecting database structures, can be enhanced to carry complex business logic rules that go beyond the scope of the database. The HasMetaAttributes trait provides an elegant way of achieving this in a Laravel application, though alternative architectural patterns might offer other advantages based on specific requirements.

As developers, we must remember that there isn't a one-size-fits-all solution. The best approach always depends on the problem at hand, the current architecture, and future scalability needs. Whichever path you choose, make sure it aligns with both the short-term and long-term goals of your application.

DEV Community: Nick Ciolpan

Building a Docker debug TUI in Rust with output-aware follow-ups

Idea 1 — typed placeholders

Idea 2 — parse stdout into typed candidates

Search across the explainers

Two surfaces from one catalog

What it isn't

Try it

How to Secure Claude CLI When It Runs Inside Your Software (don't ask)

Layer 1: Text-Only Mode

Layer 2: Strip Capabilities

Layer 3: Process Isolation

Layer 4: Prompt Validation

Layer 5: Output Containment

Combined

API vs CLI

Starting Point, Not Endpoint

Your Dockerfile Scanner Should Break the Build

The problem

Now it breaks the build

GitHub Action

New checks

Less noise

SARIF output

Install

I built a terminal-native Little Snitch alternative for macOS

What it looks like

How it works

Prompt serialization

pfctl input sanitization

Connection deduplication

What you get

Install

What it can't do

What I learned

Stop shipping insecure file permissions

DO:

Setup (30 seconds)

Best Practices

Stop Shipping Broken Docker Images

DON'T

DO

Setup (30 seconds)

Docker #DevOps #Security

TIL How to Batch Compress PDF Files Using Ghostscript

TIL: How to Quickly Check Which AWS Regions Support SES Using a Bash Script

}

SES is not available in region: us-west-1

}

Orthogonality in Programming: Why Elm Gets It Right

Beyond workarounds: DCI offers a genuine take on traditional OOP design patterns

Beyond the Hype: Rethinking Decoupled Architecture and the Pursuit of Modern Frontends

Enhancing Models with Meta Attributes: A Dive into Business Logic Beyond the Database

Carrying Business Logic with Meta Attributes

The HasMetaAttributes Trait

Application in an Eloquent Model

Architectural Considerations and Alternative Approaches

Conclusion

The `HasMetaAttributes` Trait