There are some extensions that allow you to generate a valid South African ID number but I needed all the numbers, so I built a Chrome extension that does it all for me.

The Problem

In a previous post, I mentioned working on validation for identification fields; PAYE references, SDL references, UIF references. That work made it impossible to quickly demo or use those screens. Luckily they are not all required fields but not required does not mean never used.

Every time you need to test an employee form, a company registration screen, or a tax submission flow, you need structurally valid reference numbers. Not real ones; just ones that pass the validation algorithms.

What It Does

SARS Testing Tools is a simple Chrome extension that generates six types of South African reference numbers:

• SA ID Numbers — 13 digits with Luhn check digit validation. You can filter by date range, gender, and citizenship status.
• Income Tax Numbers — 10 digits using the SARS Modulus 10 algorithm.
• Company Registration Numbers — In the YYYY/NNNNNN/XX format with 14 different company type codes.
• PAYE References — 10 digits with SARS Modulus 10 validation.
• UIF References — Prefixed with U, 10 characters total.
• SDL References — Prefixed with L, 10 characters total.

Every number it generates passes its respective validation algorithm. You can generate up to 25 at a time and copy them individually or all at once.

The Validation Algorithms

This is the part that makes generating these numbers non-trivial. You can’t just throw random digits together.

SA ID numbers use the Luhn algorithm. The first 6 digits are your date of birth, then 4 digits for gender (0000-4999 for female, 5000-9999 for male), a citizenship digit, an unused digit, and finally a check digit calculated from all the preceding digits.

SARS tax numbers (income tax, PAYE, UIF, SDL) use a variation of Modulus 10. It’s similar to Luhn but processes digits left to right instead of right to left. For PAYE, UIF, and SDL numbers specifically, the algorithm substitutes the first character with 4 before computing the check digit.

Here’s the SARS Modulus 10 implementation:

export function calculateSarsModulus10CheckDigit(digits, substituteFirst = null) {
  const arr = digits.split('').map(Number);
  if (substituteFirst !== null) {
    arr[0] = substituteFirst;
  }
  let sum = 0;
  for (let i = 0; i < arr.length; i++) {
    let val = arr[i];
    if (i % 2 === 0) {
      val *= 2;
      if (val > 9) val -= 9;
    }
    sum += val;
  }
  return (10 - (sum % 10)) % 10;
}

Not rocket science, but it’s the kind of thing you don’t want to be doing by hand every time you need a test number.

How It’s Built

The extension is intentionally simple. Vanilla JavaScript with ES6 modules, no build step, no frameworks. Each reference type has its own generator module, and shared validation logic lives in utility files.

├── popup.html / popup.css / popup.js
├── js/
│   ├── generators/
│   │   ├── sa-id.js
│   │   ├── income-tax.js
│   │   ├── company-reg.js
│   │   ├── paye.js
│   │   ├── uif.js
│   │   └── sdl.js
│   └── utils/
│       ├── helpers.js
│       ├── luhn.js
│       └── sars-modulus10.js

It runs entirely locally. The only permission it needs is clipboardWrite for the copy functionality. No network requests, no data collection, no analytics.

I used Chrome’s Manifest V3, and there’s a GitHub Actions workflow that validates the tag version against manifest.json and produces a Chrome Web Store-ready zip on each release.

Give It a Try

If you’re working with South African tax systems, payroll, or company registration flows, this might save you some time. It’s free and open source.

• Chrome Web Store
• GitHub

It’s a small tool, but its really useful.

Two Different Tools for Two Different Jobs

I’ve settled into a pattern where I use two different Claude tools for different purposes. I use the Claude Desktop App for quick, back-and-forth questions. Like when I was figuring out Flutter stuff for a potential project, or working through versioning for project’s build pipeline. It’s great for that kind of exploratory conversation where I’m just trying to understand something or bouncing thoughts and ideas around.

For actual project work where I’m making code changes, I use Claude Code.

I’m a terminal person; I’ve been on Linux/OSX for years, so I’m super comfortable in the command line. That makes Claude Code feel really natural to me.

The CLAUDE.md File is Your Secret Weapon

Here’s something that makes a huge difference: when you start a Claude Code project, you get this CLAUDE.md when you run the /init command. What it does is analyse your codebase, figure out how everything works together, what libraries you’re using, how your components are structured; basically builds this whole context about your project.

The cool thing is you can add rules to this file. Like if Claude keeps putting your controllers in the wrong directory, you just tell it in the CLAUDE.md file: “Controllers go here.” Or you can say “We’re doing TDD, so always write the test first, make it fail, then write the code.” You give it these guidelines and it follows them.

If you’re just getting started with Claude Code, I highly recommend watching this video on creating an effective CLAUDE.md file; it’s a great primer on how to set up your project context properly.

Plan Mode Changes Everything

The real game-changer for me has been plan mode. Let me give you a real example.

We had a ticket to add postal code fields to employee addresses. The team estimated it at four hours because there was front-end work, a detail view, and potentially API work if the backend didn’t support it.

I went into plan mode and basically said: “In the employee screen we have address line 1, line 2, city, postal code, province, and country. But in the company view we’re missing some of these fields.”

Claude came back with a plan. This is what I love about it; it doesn’t just start coding. It says “Okay, here’s how I’m thinking about this. I need to modify these files. Here’s what needs to change in the form. I see there’s a handle change function, I’ll need to update that. I checked your API and it already supports all these fields, so this is just a UI change.”

Then it lists out exactly what it’s going to verify to make sure it worked.

We were in standup. I hit enter on that prompt. Five minutes later, the whole thing was done. Data saving, everything looking exactly like the rest of the system. A four-hour task done in five minutes.

It’s Like Working with a Junior Programmer

Here’s how I think about Claude: it’s a junior programmer.

If I just gave a junior dev a big spec file and said “make this happen,” I’d get the same unpredictable results I’d get from Claude. You need to guide it. You need to break things down. You need to explain things.

What Claude is really good at is going through all your files, understanding how everything works together, what talks to what. It has documentation for every library you’re using. It’s just really good at that stuff.

What’s important though is you need to understand context of the environment you’re working in. If it is your junior to work with, then you need to guide it, break things down, give it the right context etc.

When I Actually Use It

Someone asked if I use it for complex business logic. Yup, I do.

For example, we had these identification fields that all needed specific validation. I had a screenshot of the requirements. I literally just copied the image, pasted it into Claude, and said “We need to add validation to these fields.”

It’s really good at understanding images and designs, especially if you already have a component system. It figures out how to make things look consistent.

But I broke it up. I told it to do the PAYE reference first. Then the SDL reference. Then the UIF reference. I didn’t just dump the whole thing on it.

Clear the Context Between Tasks

One thing I do religiously after finishing a feature, I clear the context. LLMs work better with smaller contexts. You don’t want to give it this massive history of everything you’ve ever done in the project.

I keep tasks small and focused. Plan one thing, check the plan, do the thing, clear the context, rinse and repeat.

The Planning Conversation Matters

When you’re in plan mode, Claude will ask clarifying questions if it’s not sure about something. Like when I asked it to move the address fields to the right column, it asked: “Should the same change be applied to the read-only detail view?”

It was great because in text it kind of draws out the screen with the main labels on the page. You can see visually what it’s planning to do before it does it. You can catch mistakes early. You can say “Actually, no, put the address at the bottom, not the top.”

It’s like pair programming. You’re having a conversation about what needs to happen.

I Still Review Everything

This is critical: you still need to review your code.

I still use my IDE to look at diffs. I go through each change and make sure it makes sense. I’m checking that it didn’t break anything. I’m verifying the logic is correct.

Claude is a tool, not a replacement for thinking. I’m the one who understands the problem, makes the decisions, and takes responsibility for the code. Claude just helps me get there faster.

Cross-Project Work

Oh, and another thing—Claude can work across projects. On one of my projects, I’ve given it access to both the main UI project and the API/data projects. It knows about both. So when I’m making a change in it, it can go check the API to see if it already supports what I need.

You just tell it in the CLAUDE.md file where these other projects are, and it does the rest.

Just Start Using It

My advice? Just start using it. Even if you’re not having it write code for you, use it to ask questions about the codebase. Use it to understand problems and potential solutions. Ask it why it did something. Don’t just accept the code and move on. Use it as a learning tool. Build your understanding as you go.

It’s not about having the tool do everything for you. It’s about getting into the habit of using it to help you work more effectively. The four-hour tasks that take five minutes? Those add up. But only if you actually use the tool.

There’s So Much More to Explore

I should mention what I’ve shared here is really just scratching the surface. There’s a whole ecosystem around Claude Code that I’m still learning about.

Skills, for instance. You can create custom skills that teach Claude how to do specific things in specific ways for your projects. Think of them like specialised training modules.

Then there are MCP servers that let Claude integrate with external tools and services. Want Claude to interact with your Slack workspace? Your Google Drive? Your database? MCP servers make that possible.

Some people are even creating orchestration setups where they use different Claude models for different tasks. Opus for planning and strategy, Sonnet for the actual coding, specialized agents for code review. They run tasks in parallel. It’s pretty wild what’s possible.

Well, I was wrong. Or at least, I was seeing it in black and white when there’s a whole lot of grey in between.

About a month ago, I went back to the office at Digital Solution Foundry. Full time. Not hybrid, not a couple days a week - full time. And it’s completely challenged how I think about remote work.

What Changed?

Here’s the thing; I still think remote work is great. But I’ve realized it’s not great for everything. And that’s a tough pill to swallow when you’ve been so vocally pro-remote-only for years.

At DSF, we have this core value around lifting people up. We take on interns, junior developers, people who might only have a year or less of experience (or even none). We’re not just building software; we’re teaching people how to build software. We’re helping them learn the craft, grow their skills, become better developers.

And that’s where remote work showed its limitations for us.

The Goldmine of Organic Conversations

And that’s where remote work showed its limitations for us. In the last month, I’ve noticed something I completely missed when I was remote. There are these little conversations that happen organically in an office that you just don’t get over Slack or Microsoft Teams.

Research backs this up in a big way. A study from Harvard, the Federal Reserve Bank of New York, and the University of Iowa found that software engineers received 22% more feedback on their code when working in the same building as their teammates.¹ Another study estimated that between 25-70% of work time is spent in face-to-face interactions, and roughly 30% of those are casual conversations; the kind that happen around the proverbial water cooler.²

A junior developer is stuck on something. Instead of posting in a channel and waiting for a response, they turn to the person next to them. That person might be just as junior, and they work through it together; sometimes incorrectly, sometimes brilliantly. And I get to be there for that. I can jump in, not to take over, but to show them how a seasoned developer thinks about the problem. How to ask the right questions. How to get to the actual problem instead of plastering over a symptom. Oh and don’t forget the good old whiteboard and markers… unbeatable!

These aren’t scheduled mentoring sessions. They’re not formal pair programming exercises. They’re just moments. Quick five-minute conversations that happen because someone’s struggling and someone else is nearby. And those moments have been an absolute goldmine. Gallup research found that these informal workplace interactions can improve team performance by up to 50%.³

The Nuance I Missed

Look, I’m not saying remote work is bad. I’m saying it depends.

For well-established teams with experienced developers who know what questions to ask and how to dig into problems? Remote works perfectly. Everyone has enough experience to be autonomous. Everyone knows how to communicate effectively asynchronously. The system works.

But when you’re building people up, when you’re teaching, when you’re creating an environment where inexperienced developers can learn from each other and from more experienced folks? That’s harder to replicate remotely. Studies have shown that remote and hybrid environments often fail to have effective structures to integrate, onboard, and train junior staff - which might explain why employee engagement has been declining in remote settings.⁴

And here’s something that really stood out to me: companies with formal mentoring programs see a 50% increase in employee engagement and retention.⁵ But the research also shows that less experienced workers struggle more with remote mentorship - they’re often unsure about the appropriate mode of communication, hesitant to reach out, and miss out on the kind of spontaneous learning that happens when you’re physically near more senior colleagues.⁶

I used to think any company that couldn’t make remote work was just doing it wrong. And maybe some are. But I’ve realised that what you’re trying to achieve matters. Sometimes you’re building a product, and sometimes you’re building people and the by-product is the product.

What I Believe Now

Remote work is still the most flexible way to work. It offers freedom that’s hard to beat. But it’s not always the best way to work for what you’re trying to accomplish.

If you’re building with a team of senior developers working on a well-defined product? Remote might be perfect.

If you’re trying to create a learning environment where junior developers can grow through osmosis, through those little moments of connection and teaching? You might need people in the same physical space, at least some of the time.

The answer isn’t “remote is always better” or “office is always better.” The answer is “it depends on what you’re building and who you’re building it with.”

References

Well, I was wrong.

I decided to give Dia another shot after seeing their release notes on tab groups, and I have to say, I’m pleasantly surprised. Actually, I’m more than pleasantly surprised; I’m genuinely optimistic about where this browser is headed.

What Changed?

Let me address the exact concerns I had in my original post, because Dia has either fixed them or I’ve come to appreciate their approach differently this time around.

Spaces (Profiles) Are Actually… Fine?

Look, I’m not going to pretend that Dia’s profiles work exactly like Arc’s spaces. They don’t. But here’s the thing; I was so focused on how they were different that I didn’t appreciate how they could work for me.

Yes, they still open in separate windows. Yes, the navigation isn’t quite as slick as Arc’s mouse gesture switching. But after using them for a bit, I’ve found they actually fit my workflow really well. The separation is more pronounced, which means when I’m in my work profile, I’m in my work profile. No accidental mixing of personal and work stuff. It’s grown on me.

The Sidebar Is Here!

This was a big one for me. When I first tried Dia, having tabs only at the top felt like a step backwards. I know they did add this feature in a while back but it was still not great. They still had no folders but that’s changed. What is great though is seeing how they have been listening and adding features in like the sidebar, thoughtfully. I can toggle between top and side tabs based on what I’m doing, but I find myself using the sidebar most of the time. It just feels right having that vertical real estate back on a large screen.

Tab Groups: Almost Better Than Folders

Here’s where Dia really surprised me. Their new tab groups feature (released in December) is… really good? Like, really, really good.

They’re colour-coded, which makes scanning through my work so much easier. I can organize by project, by client, by whatever makes sense at the time. They’re customisable and they stay put, so when I come back to my work, everything is exactly where I left it. The tab groups with the colour coding feels good and quick to recognise where I am and where I want to be.

There are still no live folders for things like GitHub Pull Requests but that is no deal breaker. Would be really great if they did add live folders back in but in a smart way that work with more providers or in some kind of plugin way that the community could contribute to. That would be pretty awesome.

Splits Are Here Too

Tab splits. They’re here. I can put my Figma designs next to my working code. I can compare documents side by side. It works exactly like I need it to work. Check that box.

What I’m Excited About

The team is clearly listening to feedback. They’re not just building an Arc clone; they’re building something that learns from Arc’s strengths while going in their own direction. Looking at their release notes, they’re shipping meaningful updates.

The fact that they’ve added features like picture-in-picture for Google Meet, focus mode, and are constantly refining their AI capabilities shows they’re playing the long game. They’re not just trying to win back Arc users with feature parity; they’re building toward something bigger.

And that AI integration? I haven’t fully explored it yet, but I’m keen to see how valuable it becomes. The Skills feature, the ability to interact with tabs contextually, the Memory system. They’re genuinely trying to reimagine what a browser can do for you. If they can make these AI features truly useful rather than just flashy, Dia could end up being something really special.

The future of Dia looks genuinely bright. The Browser Company learned a lot with Arc, and now they’re applying those lessons with clear intention and impressive execution. I’m excited to be along for the ride.

The Verdict

I’m moving to Dia. Not begrudgingly. Not with reservations. I’m genuinely excited to use it.

Arc was incredible, and it’ll always be the browser that showed me what a browser could be. But Dia has answered my concerns, addressed my pain points, and shown me they’re committed to making a browser that works for real workflows.

See you on the other side.

Rather than compromise, I decided to recreate the Omarchy experience on macOS (sort of). This post documents my journey building a sophisticated tiling window manager setup using yabai, sketchybar, and skhd - bringing the Omarchy philosophy to the Mac.

The Vision

What makes Omarchy special isn’t just the tiling - it’s the philosophy behind it:

• Keyboard-first interaction: Mouse usage should be minimal
• Instant workspace switching: No animations, no delays
• Clean aesthetics: Sharp corners, minimal chrome, purposeful design
• Focus-driven workflow: One task, one workspace, maximum concentration

While I can’t run Hyprland on macOS, I can absolutely adopt these principles using the right tools.

The Foundation: yabai + sketchybar + skhd

My setup relies on three complementary tools:

• yabai: A tiling window manager that gives us BSP (Binary Space Partitioning) layouts and workspace management
• sketchybar: A customizable status bar that replaces the macOS menu bar
• skhd: A hotkey daemon for binding keyboard shortcuts

Together, these tools transform macOS into a keyboard-driven, tiling-focused environment that feels remarkably close to Omarchy.

The Scripting Addition Challenge

Getting full workspace control with yabai required installing its “scripting addition,” which meant partially disabling System Integrity Protection (SIP). This was one of the trickier aspects of the setup - I had to reboot into Recovery Mode and selectively disable certain SIP protections while keeping others enabled for security.

After modifying SIP, I installed yabai’s scripting addition and configured passwordless sudo for it in /private/etc/sudoers.d/yabai so it could load automatically on startup. I added sudo yabai --load-sa at the top of my ~/.config/yabai/yabairc to ensure it loads every time yabai starts.

yabai Configuration: Tiling That Works

My yabai configuration is focused on creating a clean, predictable tiling environment:

# BSP layout for automatic tiling
yabai -m config layout bsp

# Padding and gaps for visual breathing room
yabai -m config top_padding    42  # Accounts for sketchybar height
yabai -m config bottom_padding 8
yabai -m config left_padding   8
yabai -m config right_padding  8
yabai -m config window_gap     8

# Mouse follows focus for smoother workflow
yabai -m config mouse_follows_focus on

# Keep certain apps floating
yabai -m rule --add app="^System Settings$" manage=off

The padding configuration is crucial - the 42-pixel top padding accounts for my 34-pixel sketchybar plus some margin, preventing windows from sliding over my sketchybar.

Opening apps on certain workspaces

One of the pros of this setup is getting into a flow with how you work. One of the other things that I did was to open certain apps on certain workspaces. This adds to the predictability of always knowing which of my common apps are where so when I need to message someone on slack I know its on workspace 3 always etc.

yabai -m rule --add app="^Arc$" space=1
yabai -m rule --add app="^Ghostty$" space=2
yabai -m rule --add app="^Microsoft Teams$" space=3
yabai -m rule --add app="^Slack$" space=3
yabai -m rule --add app="^WhatsApp$" space=4
yabai -m rule --add app="^Signal$" space=4
yabai -m rule --add app="^Discord$" space=4
yabai -m rule --add app="^Proton Mail$" space=5
yabai -m rule --add app="^Mail$" space=6
yabai -m rule --add app="^Calendar$" space=6

I did however run into some really strange behaviour doing this. Often for some reason suddently all my workspace 2 apps were on workspace 1 or 3 were on 4! That is when I found out that MacOS does some fancy workspace fiddling depening on how you use them.

To disable this you can easily do it in System Settings, go to Desktop & Dock and unchecking Automatically rearrange Spaces based on most recent use.

Multi-Monitor Support

One of the key improvements I made was proper multi-monitor support. When I connect my external display, I want spaces 1-6 on my main monitor and spaces 7-12 on the secondary display. This required careful configuration of both yabai and sketchybar to understand display relationships.

sketchybar: The Minimal Status Bar

My sketchybar configuration embraces minimalism while providing essential information:

# Bar appearance - dark with sharp corners
sketchybar --bar position=top \
                 margin=0 \
                 y_offset=0 \
                 corner_radius=0 \
                 height=34 \
                 color=0xC0000000

# Defaults for all items - light grey text on dark background
default=(
  padding_left=0
  padding_right=4
  icon.font="JetBrainsMono Nerd Font:Regular:14.0"
  label.font="JetBrainsMono Nerd Font:Regular:14.0"
  icon.color=0xff9e9e9e
  label.color=0xff9e9e9e
  icon.highlight_color=0xffffffff
  label.highlight_color=0xffffffff
)

Workspace Indicators

The workspace indicators dynamically update to show which spaces belong to which display:

# Add space items
for i in {1..10}; do
  sketchybar --add space space.$i left \
             --set space.$i \
                   associated_space=$i \
                   icon=$i \
                   script="$PLUGIN_DIR/spaces.sh"
done

The spaces.sh plugin queries yabai to determine the current space and display, highlighting the active workspace.

Status Items

On the right side, I keep things minimal but informative:

• WiFi: Shows connection status
• Battery: Current charge level
• Volume: Audio level indicator
• Clock: Time display

Each uses a simple plugin script that updates on relevant events.

skhd: Keyboard-Driven Everything

The real magic happens in my skhd configuration. I’ve mapped every window management operation to keyboard shortcuts, drawing inspiration from both Omarchy and vim:

Window Management

# Terminal
cmd - return : ghostty +new-window

# Window operations
cmd - w : yabai -m window --close
cmd - t : yabai -m window --toggle float
cmd - f : yabai -m window --toggle zoom-fullscreen

# Focus windows (vim keys)
cmd - h : yabai -m window --focus west
cmd - j : yabai -m window --focus south
cmd - k : yabai -m window --focus north
cmd - l : yabai -m window --focus east

# Move/Swap windows
cmd + shift - h : yabai -m window --swap west
cmd + shift - j : yabai -m window --swap south
cmd + shift - k : yabai -m window --swap north
cmd + shift - l : yabai -m window --swap east

# Resize windows
cmd + alt - h : yabai -m window --resize left:-30:0
cmd + alt - j : yabai -m window --resize bottom:0:30
cmd + alt - k : yabai -m window --resize top:0:-30
cmd + alt - l : yabai -m window --resize right:30:0

Workspace Switching

The workspace switching is designed to work seamlessly across multiple displays:

# Switch to workspace (accounts for multi-monitor)
cmd - 1 : yabai -m space --focus $(yabai -m query --displays --display | jq '.spaces[0]')
cmd - 2 : yabai -m space --focus $(yabai -m query --displays --display | jq '.spaces[1]')
# ... through cmd - 0

# Move window to workspace
cmd + shift - 1 : yabai -m window --space $(yabai -m query --displays --display | jq '.spaces[0]')
cmd + shift - 2 : yabai -m window --space $(yabai -m query --displays --display | jq '.spaces[1]')
# ... through cmd + shift - 0

# Quick workspace navigation
cmd - tab : yabai -m space --focus next || yabai -m space --focus first
cmd + shift - tab : yabai -m space --focus prev || yabai -m space --focus last

Monitor Management

# Switch between monitors
cmd + ctrl - left : yabai -m display --focus west
cmd + ctrl - right : yabai -m display --focus east

# Move window to another monitor
cmd + shift + ctrl - left : yabai -m window --display west; yabai -m display --focus west
I did however run into some really strange behaviour doing this. Often for some reason suddently all my workspace 2 apps were

Layout Management

# Layout operations
cmd - e : yabai -m window --toggle split
cmd - b : yabai -m space --balance
cmd - r : yabai -m space --rotate 270

Screenshots

I wanted screenshot functionality since often I need to take screenshots to attach to my PRs. What I did was add configs to allow me to either take a full screenshot, an interactive screenshot (both to files) and then one that goes straight to clipboard:

# Screenshots using 's' key
cmd + shift - s : screencapture -x ~/Desktop/screenshot-$(date +%Y%m%d-%H%M%S).png
cmd + alt - s : screencapture -i -x ~/Desktop/screenshot-$(date +%Y%m%d-%H%M%S).png
cmd + ctrl - s : screencapture -i -c -x

The -x ensures that you don’t hear that camera noise that screenshots normally makes. Nice and quiet.

The Workflow

With this setup, my typical workflow looks like this:

1. Launch terminal: cmd + return opens a new Ghostty window
2. Switch workspaces: cmd + 1 through cmd + 0 for instant workspace switching
3. Focus windows: cmd + h/j/k/l for vim-style navigation
4. Move windows: cmd + shift + h/j/k/l to swap window positions
5. Multi-monitor: cmd + ctrl + left/right to switch between displays

Everything is keyboard-driven, instant, and predictable. No animations, no delays - just pure efficiency.

Dotfiles Integration

One of the benefits of using GNU Stow is how seamlessly this integrates with my overall dotfiles setup. My yabai, sketchybar, and skhd configurations live in their standard locations:

• ~/.config/yabai/yabairc - yabai window manager config
• ~/.config/sketchybar/sketchybarrc - status bar config
• ~/.config/sketchybar/plugins/ - status bar plugins (spaces.sh, battery.sh, wifi.sh, volume.sh, clock.sh)
• ~/.skhdrc - keyboard shortcut daemon config

These are organized in my dotfiles repository and managed with GNU Stow, making it easy to version control and deploy across machines. To set up these configurations on a new machine:

cd ~/dotfiles
./install-macos.sh  # Installs all dependencies via Homebrew
# Then stow the relevant packages

This modular approach means I can selectively install just the tools I need on each machine, whether it’s my full desktop setup or a minimal configuration on a remote server.

Lessons Learned

What Works Well

• Keyboard-driven workflow: Once you internalize the keybindings, you rarely touch the mouse
• Workspace-per-task: Having dedicated workspaces for different contexts (coding, browsing, communication) reduces mental overhead
• Multi-monitor support: The dynamic workspace assignment across displays works beautifully
• Minimal aesthetics: The clean status bar and sharp window edges create a focused environment

Challenges

• SIP requirements: Partially disabling System Integrity Protection makes some users uncomfortable, though I haven’t experienced any issues
• Learning curve: There’s definitely an adjustment period when moving from a traditional windowing system
• Application compatibility: Some apps don’t play nicely with tiling (looking at you, System Settings)

Compared to Omarchy

While this setup can’t fully replicate Omarchy’s Hyprland-powered experience, it captures the essential philosophy:

• Keyboard-first interaction? ✓
• Instant workspace switching? ✓
• Clean, minimal aesthetic? ✓
• BSP tiling? ✓ (though not identical to Hyprland)

The main differences are in polish and integration - Omarchy is a cohesive Linux distribution built around these concepts, while this is a collection of tools adapted to macOS. But for daily development work on a Mac, it gets remarkably close.

Try It Yourself

If you’re interested in seeing how I’ve configured everything, check out my dotfiles repository. All my yabai, sketchybar, and skhd configurations are there, managed with GNU Stow for easy deployment.

Keep in mind this setup requires partially disabling SIP and has a learning curve as you internalize the keybindings. It’s also opinionated to my workflow - you’ll want to adapt it to your own preferences.

Conclusion

Building an Omarchy-inspired setup on macOS has transformed how I interact with my computer. The keyboard-driven workflow, combined with predictable tiling and instant workspace switching, has made me more focused and productive.

While it took some effort to configure and required compromises compared to running Omarchy natively on Linux, the result is a professional development environment that honors the Omarchy philosophy while working within macOS’s constraints.

If you value keyboard efficiency, minimal distractions, and a focus-driven workflow, I encourage you to explore tiling window management on macOS. The tools are mature, the community is active, and the productivity gains are real.

I’ve been maintaining my dotfiles for a while now, and I’ve finally settled on a setup that works really well across both my macOS machine and my Arch Linux box running Omarchy. The key to making this work? GNU Stow.

If you’re not familiar with GNU Stow, it’s a symlink farm manager. In plain English, it creates symbolic links from a central dotfiles directory to wherever your configs actually need to live. This means you can keep everything in one place, version control it all, and selectively install just the configs you need on any given machine.

Why GNU Stow?

I haven’t really tried any of the other solutions out there but Stow just clicks for me because it’s:

• Simple - It’s just symlinks. Nothing fancy.
• Modular - Each tool gets its own package that can be installed independently.
• Transparent - You can see exactly what’s linked where.
• Reversible - stow -D removes all the symlinks, no mess left behind.

The Structure

My dotfiles are organised into modular packages in ~/dotfiles, with each tool or category getting its own directory:

~/dotfiles/
├── zsh/           # Shell configuration
├── git/           # Git configuration
├── nvim/          # Neovim editor
├── zellij/        # Terminal multiplexer
├── hyprland/      # Wayland compositor (Linux)
├── macos-tools/   # macOS-specific tools
└── ...

Each package contains the files in the structure they’d normally live in your home directory. For example, the zsh package has .zshrc, .zsh-darwin.sh, .zsh-linux.sh, and so on.

The Setup Scripts

To make getting started easier, I created installation scripts for each platform. They handle package installation, prompt for optional components, and automatically stow the configs.

For Arch Linux:

cd ~/dotfiles
./install-arch.sh

For macOS:

cd ~/dotfiles
./install-macos.sh

These scripts will install the necessary packages (like zsh, neovim, zellij, fzf, etc.) and then selectively stow the configs you want.

OS-Specific Configurations

One challenge with cross-platform dotfiles is handling the differences between operating systems. I solved this with OS-specific configuration files that get sourced automatically.

In my zsh setup, I have:

• .zsh-darwin.sh - macOS-specific settings (Homebrew paths, ASDF, etc.)
• .zsh-linux.sh - Linux-specific settings (Paru AUR helper, ASDF, etc.)

The main .zshrc detects which OS you’re on and sources the appropriate file. This keeps the platform-specific cruft out of the main config.

Key Tools

Here are just some of the tools I’m using currently across both systems:

Shell & Terminal

• zsh with Zinit plugin manager and Powerlevel10k prompt
• zellij as a modern terminal multiplexer
• fzf for fuzzy finding
• eza as a modern ls replacement
• zoxide for smart directory jumping

Development:**

• Zed editor (my new favourite)
• neovim for editing
• lazygit for a nice Git TUI
• lazydocker for a nice Docker TUI
• lazysql for a nice SQL TUI

Nic

• yazi as a terminal file manager
• btop for system monitoring

Arch/Omarchy Desktop

• Hyprland as a Wayland compositor
• Waybar for status bar
• Wofi for application launcher

macOS Things

• Ghostty terminal

Using the Setup

Once you’ve cloned the repo to ~/dotfiles, using it is straightforward:

Install just the essentials:

stow zsh git nvim zellij

Full Arch Linux desktop:

stow zsh git nvim zellij hyprland wayland-tools gtk lazygit yazi btop

macOS with development tools:

stow zsh git nvim zellij macos-tools lazygit yazi btop ideavim

And if you want to remove something:

stow -D nvim

Personal Scripts and Secrets

I keep personal scripts and secrets in ~/.zsh_scripts/ and ~/.zsh_secrets/ respectively. These directories are gitignored, but any .sh files in them are automatically sourced by my zsh config. This gives me a place for machine-specific or sensitive configs that don’t belong in version control.

The Payoff

The real benefit of this setup became clear when I set up my Arch Linux machine. Instead of spending hours remembering which configs I needed and manually copying everything over, I just ran the install script and stowed the packages I wanted. Five minutes later, my terminal felt like home.

Same goes for when I inevitably mess something up. I can nuke my configs, re-stow, and be back up and running immediately. No hunting for backup files or trying to remember what I changed.

Try It Out

You can find my dotfiles at github.com/penkin/dotfiles. Feel free to use them as reference or inspiration for your own setup.

If you’ve never used Stow before, I’d highly recommend giving it a shot. It’s one of those tools that just makes sense once you start using it.

Warning

I am always playing with my dotfiles, tweaking them, and experimenting with new tools. This means that some of the configurations may not work perfectly out of the box, and you may need to make some adjustments to suit your needs.

Recently, a teammate introduced a simple but clever solution that cut our build times dramatically, a custom BUILD_CACHE property that intelligently decides when to rebuild frontend assets.

The Problem

The project is an large monolith application with many .NET projects and quite a few of them need to build javascript and/or css assets.

The issue? Every build had expensive asset rebuilds. npm ci alone can take several minutes on a fresh install, and npm run build adds even more time for webpack to do its thing.

The Solution

The fix was surprisingly elegant. Instead of always running the full npm build process, we created conditional MSBuild targets.

<Target Name="PreBuild" AfterTargets="PreBuildEvent" Condition="'$(BUILD_CACHE)' != 'true'">
  <Exec Command="npm ci" />
  <Exec Command="npm run build" />
</Target>
<Target Name="PreBuildCached" AfterTargets="PreBuildEvent" Condition="'$(BUILD_CACHE)' == 'true'">
  <Exec Command="node ../../if-changes.js" />
</Target>

When BUILD_CACHE=true, instead of blindly rebuilding everything, we run a custom Node.js script called if-changes.js that intelligently checks what’s actually changed.

How It Works

The magic happens in the package.json configuration of the various projects. We add the following onlyIfChanged section to it:

"onlyIfChanged": [
  {
    "name": "dependencies",
    "globs": [
      "package-lock.json"
    ],
    "command": "npm ci"
  },
  {
    "name": "build",
    "globs": [
      "Scripts/**/*",
    ],
    "command": "npm run build"
  }
]

The script uses file globbing (powered by fast-glob) to check specific files and directories, only when these files change does it trigger the associated commands. No more rebuilding frontend assets when you’ve only touched C# code.

Setting It Up

Here is how to set it up on both Rider and Visual Studio.

For Rider users:

Settings → Build, Execution, Deployment → Toolset and Build
Edit "MSBuild Global Properties"
Add BUILD_CACHE=true

For Visual Studio users:

There is no built in way to do this in Visual Studio so we need to make use of environment variables within Windows.

Open System Properties → Advanced → Environment Variables
Add BUILD_CACHE=true as a system variable
Restart your computer (yes, really!)

Add the conditional targets to your .csproj file shown above and configure the onlyIfChanged section in your package.json file. Don’t forget to install fast-glob as a dependency.

The Results

The speed improvement was immediate and significant. Local development builds that used to take 5-10 minutes now complete in 1 and developers stopped grabbing coffee during every build cycle (not sure if that is a win or a lose).

The results on my MacBook Pro with an M1 chip and 16GB of RAM. The gap was even more noticable on others running Windows… just saying :P

With cache    Build completed in 00:01:01.969
Without cache Build completed in 00:07:09.369

I’m reposting this one of the most underrated inventions of our time. I’ve gone from Mobi effectively not starting up on my machine anymore to it starting up within seconds. ~ One happy customer in our slack channels

The best part? It’s completely transparent. Developers who haven’t set up the caching still get working builds, they just take longer. Those who enable caching get the speed benefits without any downsides. Sometimes the best optimisations aren’t about fancy new tools or frameworks; they’re about being smart about when you choose to skip work entirely.

Bonus

Here is a link to the GitHub gist of our if-changes.js file.

Below is a brief overview of the stack I used to build this blog.

The stack

• Jekyll
  • Jekyll Paginate
  • Jekyll Feed
  • Jekyll Sitemap
• Tailwind CSS
• GitHub Pages

Jekyll

Jekyll is a static site generator that can be used to build a static websites like this little blog. What makes it great is that you can create your content in something simple like Markdown and Jekyll will take care of the rest. It also has some nice little features that let you organise your files in ways that are easy to maintain. You can have various layout files to define the structure of your pages and posts, and you can use Front Matter to define metadata for your pages and posts.

I chose Jekyll mainly because it seemed really simple to get started. The main purpose of this blog is to practise writing, I did not want to get bogged down with complex setups, CI/CD pipelines etc. Jekyll is a great fit especially when hosting the site within GitHub Pages as it has a very low barrier to entry. There is a Ruby dependency but as a software developer I already had that installed.

The other great thing about Jekyll are the plugins. Below are the plugins that I used.

Jekyll Paginate

Jekyll Paginate is as simple as it sounds. It adds a paginator object to your page that you can then show a page of posts and add some navigation to move between the pages. You can then use paginator.posts to iterate through to show that page’s posts and paginator.total_pages, paginator.previous_page and paginator.next_page to construct your paging navigation.

To get pagination working you’ll need to include jekyll-paginate in your Gemfile and add the following to your _config.yml file where paginate is the number of items you want on the page and paginate_path is the URL path to the page.

paginate: 10
paginate_path: "/blog/page:num/"

plugins:
  - jekyll-paginate

Note that pagination only works in html files and not markdown files.

Jekyll Feed

Jekyll Feed adds all that Atom/RSS magic to the blog so that readers can read your posts from the comfort of their own feed readers.

Again a pretty simple setup that has you adding jekyll-feed to your Gemfile file. The config is also pretty straightforward. All I did was to update the icon with the following:

feed:
  icon: /assets/img/favicon-192x192.png

plugins:
  - jekyll-feed

There are a lot more config options available but I kept mine simple with the above but you can see the rest here.

Jekyll Sitemap

Jekyll Sitemap helps with all that search engine love. I added it to generate a sitemaps.org compliant sitemap to help with indexing the site on various search engines.

Oh and guess what? That’s right! Add jekyll-sitemap to your Gemfile file and in the config you would add the url and the plugin name to the plugins section.

url: "https://www.penkin.me"

plugins:
  - jekyll-sitemap

Tailwind CSS

Tailwind CSS is a beautiful composable CSS framework that allows you to build your design within HTML. When I initially planned to start blogging again I wanted to also make this a little space that I can play around in. One of those things was to play more with Tailwind as well as implement dark mode abilities within the site and whatever else catches my fancy in the future.

Tailwind has some comprehensive getting started guides on how to use it within your site or app.

What I did to keep things simple within this blog is to simply add the following build scripts within my package.json file:

{
  "scripts": {
    "build:dev": "npx @tailwindcss/cli -i ./src/css/main.css -o ./assets/css/main.min.css --watch",
    "build:prod": "NODE_ENV=production npx @tailwindcss/cli -i ./src/css/main.css -o ./assets/css/main.min.css --minify"
  }
}

All it’s doing is taking my input CSS file and outputting it to the assets folder after tailwind does its magic. I have not set up any CI/CD pipelines to automate the build of the CSS currently as it almost never changes. I wanted to focus on the writing aspect of this site and if I change any styles I simply run the npm run build:dev while I build. Once I am happy I run npm run build:prod and commit the file.

GitHub Pages

GitHub Pages is a free static site hosting service offered by GitHub. Nothing beats free and they also have some Jekyll is fully supported for simple little sites like this one.

Since I am hosting within GitHub Pages, I added the following to the Gemfile, gem "github-pages", group: :jekyll_plugins. The github-pages gem ensures my local development environment matches exactly what GitHub Pages will build, preventing the frustrating situation where my site works perfectly locally but breaks when deployed.

GitHub Pages does have a default set of plugins that it supports out of the box that helps you get setup with no mess or fuss. I believe though if you do want to go outside of these defaults that there is some additional setup that is required. I did not need anything outside of what I have above so it all just worked.

What’s Next?

Next I guess is writing. The plan is to focus on getting one post out every month, if there are more, great, if not, fine. The setup is simple so that I can get that done. If I see some CSS or JS stuff I want to try I can also play with that here. Time will tell.

For now though… write. Commit. Push. Done!

You can see all the code at https://github.com/penkin/penkin.github.io.

UPDATE: I more recently wrote about how my opinion on Dia has changed. See my updated thought here.

It’s wild to me that The Browser Company took a browser with an almost cult following to just drop it completely to follow what was apparently their initial vision. It leaves me wondering though, if Arc was not the original vision did they perhaps stumble into something that was too good to be true?

When I was first introduced to Arc I did not think the hype was real. Surely a browser is a browser is a browser… right? Nope! Arc just felt right. It had lots of little hidden gems that just worked well and that first install; sublime! I still remember selling it so hard at work, getting everyone to try it and many of them loved it too.

I have to say that I was a bit disappointed when I first tried Dia. It felt like I was just using Chrome again but had some AI secret sauce. What I loved in Arc is just not there in Dia and it’s just too much that I can’t switch over to Dia.

Even one of the people I got onto Arc initially also tried Dia and soon as he saw he needed a whole new account to use it he just didn’t even bother. The friction was too high.

So understand what I write below is not to smear Dia but to highlight the little things in Arc that I just cannot live without and ultimately leaves Dia packed away in my Applications folder, never getting its time to shine.

Spaces

The thing that I probably hate the most is how spaces work in Dia as apposed to Arc. Arc’s spaces are super simple to navigate between with the mouse. I generally have four spaces that I keep everything separate in. I have work, clients, personal etc. I can easily switch between them in Arc and it has a single window when I switch.

Dia on the other hand shows a new window per space (profile)?! I find it clunky to navigate with the mouse because I have to go to the little colour space button, click it and select the space I want to go to; even the keyboard shortcut shows the profiles menu then over to the arrow keys. Nope, nope, nope! With Arc I can be anywhere in the sidebar and hit the left and right buttons on my mouse to navigate between spaces. I think this is my No. 1 worst change between Dia and Arc.

Sidebar

Until two weeks ago Dia had no sidebar, it was back to tabs only at the top. That is neither here nor there really but initially I missed the option to have it how I got used to using a browser in Arc. Even though it’s not a massive deal it’s an interesting choice when you are hoping to attract your existing user base, was it to clearly indicate that they’re not Arc anymore?

I’m glad however that the sidebar is now there but it’s really limited. I mean really really REALLY limited.

So, what are these limitations, you ask? Folders and an extension on that; live folders. There is no way to organise your tabs which I used a lot in my dev work. So none of the bells and whistles that were once there, basically just the tabs at the top can now be on the side.

Folders

Depending on the client I’m working with, they often have multiple environments and folders makes it super simple to organise all of that. Do I need to test something in QA, it’s all there in the QA folder. UAT? Oh yes, right there in the UAT folder. Dia just does not have the ability to do that.

The “same thing” in Dia is just the normal bookmarks bar from 1993.

Live folders

As a developer, I found the GitHub live folders almost too useful. The live folder would automagically update with any new pull requests that were open and assigned to me. No need to check mails for new requests coming in, or going to GitHub to check. Nope, all just there in all its glory. Guess what; again; Dia does not have this feature.

Tab Splits

Being able to put tabs side by side or below each other was something I use in Arc. I found it useful when I was working on some UI changes to have the Figma design next to the working tab to compare the two. Again Dia does not have this feature.

Copy URL

This is such a tiny thing but I think it just shows that they were not exaggerating when saying they were starting Dia from the ground up. They left out all the cool things about Arc right down to the little copy URL button in the URL bar. Just everything is gone and it’s just a Chrome browser with AI chat built in that can look at all my tabs and I guess help me with all that?

Love Letter

So again I am not writing this to bash Dia but rather as a love letter from an Arc user to just say Arc was incredible for all the little things it had and how it made working in a browser that much easier. Dia is just not that. Maybe when testing with college students it makes sense because as they study they may have many tabs open on subjects that they need summarised and organised etc. Maybe Dia is good at that but I have tried and I can’t see how Dia is better than Arc in how it has gotten me to use my browser. It’s just too much friction for me to move to Dia.

I think the other concern I have is that with Dia the primary love I see Arc getting is mostly around security fixes and brining in the latest Chromium, which I am grateful for, but it also means with Dia that Arc will stagnate quickly. There is hope though on the horizon in the shape of the Zen browser.

Zen Browser

They have started implementing a lot of the features from Arc using Firefox as the base. They don’t have folders or live folders yet but it is being worked on here and here. It’s available to download on Windows, MacOS and Linux. Be keen to see how it turns out and a pro if it does replace Arc for me is that I can use it on my Linux machine as well.

Here’s what we covered:

1. AI and Software Development
2. What Agentic Development Means
3. Introduction to the Model Context Protocol (MCP)
4. Live Demo

AI-Powered Development Tools

Today’s developers are spoiled for choice when it comes to AI-enhanced tools. Whether you’re writing boilerplate code, critiquing code, or generating tests, AI is finding its way into every dev workflow.

Here are just a few tools to know:

• GitHub Copilot: Needs no introduction at this point.
• Cursor: Offers rich inline suggestions, feels snappy and intuitive.
• Windsurf: Another AI-driven environment built off Visual Studio Code.
• JetBrains AI: Integrated assistant for IntelliJ-based IDEs.
• Zed: Lightweight, with an AI co-dev baked in.

All of these tools offer variations of:

• Autocomplete magic
• Automated boilerplate generation
• Generating tests with almost no mental overhead

Ultimately, AI has the potential of making developers faster and more efficient—turning high-level ideas into runnable code more quickly than ever.

So, What is “Agentic AI”?

“Agentic” AI refers to systems capable of taking initiative and making decisions on their own. You don’t just command them step-by-step — they can autonomously plan and act.

An agentic AI doesn’t just respond; it draws from its internal model, gets context, plans a task, and implements the code — end-to-end.

However, there’s a big caveat.

Agents are only as good as the access and instructions you give them. If the inputs are unclear or the data and scope are limited, you’ll get unclear or incorrect outputs.

Kent Beck calls it his “genie.” You get exactly what you asked for, not what you meant to ask for.

What is the Model Context Protocol (MCP)?

Here’s where things get really interesting.

The Model Context Protocol (MCP) is shaping up to be a powerful paradigm in the AI workflow. MCP allows AI models to talk to tools via structured, documented interfaces.

Think of it like plug-and-play for tools + AI. We’re starting to get into the realms of this being our very own Jarvis for Ironman. You can take something like Claude Desktop and connect it to various tools to create a personal assistant that knows about your data and can act on your behalf.

I’m not sure how ready I am for this step to be frank but the thought of being able to talk to an AI that knows my calendar, my mails, my Notion documents… has my nerdy senses tingling. Who knows, maybe my memory is short since it was not that long ago I wrote about leaving Facebook and Google behind.

Docker is doing something pretty interesting here, they are creating a hub for MCPs that allow you to run contanerised versions of these tools. So you can install one for Postgres and/or Graphana and/or GitHub and then chat to your AI about your data in these external apps.

I still want to play around with Notion’s MCP server and see how that pans out. I’m imagining that I can use Claude to add to my notes, summarise them etc. Really keen to see where this all goes.

This isn’t just chat-based prompts anymore. It’s AI with real-world integrations, acting like a personal agent across all your services.

Final thoughts

I really love where this is going so far, it’s really interesting using and playing with all these shiny toys. They are however still in flux. So keep playing, don’t tie into any one service. They are all improving and evolving. Try things out and see where it takes you.