Skip to content
Michael P. Porter

How I Use My Tools

I’m a DevSecOps engineer, so pipelines, automation, and “make the boring thing reliable” are second nature at work. I bring the same instincts home — just pointed at my notes, my tasks, and my house instead of production systems.

This section is a running log of the tools I actually use, how I think about them, how I keep them fast, and how I keep them from rotting. Nothing here reflects a specific employer’s infrastructure — the CI/CD pages describe general principles, and the personal-tool pages describe generic, reproducible setups anyone could stand up.

The stack, roughly

Section titled “The stack, roughly”

Personal knowledge, tasks, and thinking

  • Obsidian — my PARA-organized vault, with Breadcrumbs for structured note relationships. This is where thinking happens.
  • OmniFocus — where thinking turns into doing. Tasks live here, not scattered across sticky notes or buried in a notes app.
  • Due — the nag layer for the handful of things a single silent notification won’t catch.
  • Readwise — highlight capture and read-later, feeding straight into the vault.
  • Claude — a coding partner and a thinking/planning partner, used across all of the above.

CI/CD, professional context

  • Jenkins — CI proper: build, test, and parameterized builds.
  • Concourse — declarative, resource-driven pipelines; a natural fit for cron-style scheduled jobs.
  • ArgoCD — GitOps deployment, kept deliberately separate from CI.
  • Kargo — progressive promotion between environments, downstream of ArgoCD.
  • GitHub Actions — CD for GitHub-native projects, plus Dependabot for dependency hygiene.

Desktop & life

  • Magnet — fast, in-the-moment window snapping.
  • Moom — saved, recallable multi-window layouts.
  • Overcast — podcasts, kept to a listening surface rather than storage.
  • YNAB — zero-based budgeting, feeding a longer-range financial model.

Home

  • Homebridge — bridges the odds and ends of home automation into HomeKit.

Why write this down publicly

Section titled “Why write this down publicly”

Partly for myself — a setup I can rebuild from scratch after a hardware failure or a bad upgrade. Partly because most “here’s my setup” writeups either skip the boring maintenance details or never mention performance until something breaks. I’d rather document the unglamorous parts: update cadence, resource limits, and the small tuning decisions that keep these tools fast enough that I actually keep using them.