DEV Community: Sven Schwyn

Bootable macOS Tahoe Installer and Clean Install

Sven Schwyn — Wed, 17 Sep 2025 10:46:09 +0000

For clean installs of macOS or installs on multiple computers with only one download, creating a bootable macOS installer on a USB drive is the way to go.

Up to Sequoia, Apple released standalone installers for the major releases of macOS on the App Store. For Tahoe, however, there's no such thing and probably never will. The installer is available on third-party download sites, but it is an incredibly bad idea to use any of them, no matter how trustworthy it may look. Just don't do it!

Also, there's no reason to take such unnecessary risks – with a little help of the Terminal.

Create a Bootable USB macOS Installer

You'll need a big enough USB drive. Use the Disk Utility to erase it to HFS+ format and the default name /Volumes/Untitled. Then launch the Terminal and:

# Find the installer for the version of macOS you wish to install
softwareupdate --list-full-installers

# Download the installer app
softwareupdate --fetch-full-installer --full-installer-version {VERSION}

# Create a bootable installer on the USB drive:
sudo "/Applications/Install macOS {MACOS_NAME}.app/Contents/Resources/createinstallmedia" --volume /Volumes/Untitled

That's it, easy as 123 and free as in free beer!

Clean Install

I won't go into much detail here, but the basic steps are as follows:

Create a Time Machine backup.
Create a second, full backup using SuperDuper, Carbon Copy Cloner or a similar tool.
Make sure you have successfully completed the steps 1 and 2.
Attach the USB drive containing the installer.
Shut down your Mac, then restart it into boot options: On an Apple Silicon Mac, push and hold the power button. On an Intel Mac, push the power button, then hold the option key (⌥).
Use the Disk Utility to erase the startup disk to APFS.
Use the macOS installer on the USB drive to clean install macOS.
Migrate your data from one of the backups onto the fresh macOS.

(Image by Leehu Zysberg)

Mini Monads

Sven Schwyn — Thu, 30 Jan 2025 19:33:49 +0000

Here's a quick bite for those using result monads provided by dry-monads to code workflows and test them with Minitest . Nothing fancy, please leave suggestions to make it more useful in the comments.

As a quick reminder: Result monads are simple objects which wrap the return value of methods in a uniform manner thus turning them into building blocks which can be stacked on top of one another like Lego bricks. Operations in Hanami 2 make use of them thru dry-operations, a thin extra layer which adds steps to the mix. Together, these great gems can turn a bowl of messy if/then/else/rescue spaghetti into a well layered lasagne. You can eat both of them alright, but only the lasagne will earn you applause for the optics and the ability to add more layers ad lib.

You still want to test this though, so here are the custom Minitest (assertions and) expectations for the job.

Minitest 6 or newer:

# frozen_string_literal: true

require 'dry-monads'

module Minitest::Assertions
  def assert_success(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} to be Success with #{mu_pp(expected)}" }
    assert(expected == actual.value!, msg)
  end

  def refute_success(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} not to be Success with #{mu_pp(expected)}" }
    assert(expected != actual.value!, msg)
  end

  def assert_failure(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} to be Failure with #{mu_pp(expected)}" }
    assert(expected == actual.failure, msg)
  end

  def refute_failure(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} not to be Failure with #{mu_pp(expected)}" }
    assert(expected != actual.failure, msg)
  end
end

module Minitest::Expectations
  infect_an_assertion :assert_success, :must_be_success
  infect_an_assertion :refute_success, :wont_be_success

  infect_an_assertion :assert_failure, :must_be_failure
  infect_an_assertion :refute_failure, :wont_be_failure
end

Minitest 5:

# frozen_string_literal: true

require 'dry-monads'

module Minitest::Assertions
  def assert_success(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} to be Success with #{mu_pp(expected)}" }
    assert(expected == actual.value!, msg)
  end

  def refute_success(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} not to be Success with #{mu_pp(expected)}" }
    assert(expected != actual.value!, msg)
  end

  def assert_failure(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} to be Failure with #{mu_pp(expected)}" }
    assert(expected == actual.failure, msg)
  end

  def refute_failure(expected, actual, msg=nil)
    msg = message(msg) { "Expected #{mu_pp(actual)} not to be Failure with #{mu_pp(expected)}" }
    assert(expected != actual.failure, msg)
  end
end

Dry::Monads::Success.infect_an_assertion :assert_success, :must_be_success
Dry::Monads::Success.infect_an_assertion :refute_success, :wont_be_success

Dry::Monads::Failure.infect_an_assertion :assert_failure, :must_be_failure
Dry::Monads::Failure.infect_an_assertion :refute_failure, :wont_be_failure

Say you want to test the following nonsensical example:

class Lasagne
  include Dry::Monads[:result]  

  def cooking_time(tool)
    case tool
      when :microwave then Success(10)
      when :oven then Success(30)
      when :nuke then Failure(:epic)
      else Failure(:unsupported_tool)
    end
  end
end

Here are the tests in spec notation (because I like it so much better than assertions):

describe Lasagne do
  subject { Lasagne.new }

  it "quickly cooks in a microwave (but don't tell any Italians)" do
    _(subject.cooking_time(:microwave)).must_be_success 10
  end

  it "cooks perfectly in an oven" do
    _(subject.cooking_time(:oven)).must_be_success 30
  end

  it "ends us all when using a :nuke" do
    _(subject.cooking_time(:nuke)).must_be_failure :epic
  end

  it "doesn't cook with just any tool" do
    _(subject.cooking_time(:nose_hair_trimmer)).must_be_failure :unsupported_tool
  end
end

You can of course do without, but I find the vanilla alternative less appealing:

it "cooks perfectly in an oven" do
  _(subject.cooking_time(:oven)).must_equal Dry::Monads::Success(30)
end

Bon appetit!

Banner image by Rainer Stropek

Client side Git hooks 101

Sven Schwyn — Sun, 31 Mar 2024 12:50:36 +0000

Git hooks are simple yet powerful, essentially just scripts executed when certain events like commit or push occur. Most notably, they are really useful for enforcing code and commit quality. However, there's one problem: Since the hook scripts are stored inside the .git/ directory, they cannot be committed to the repository and shared with other developers as is. Let's see what we can do about this.

(Side note: Every fresh Git repository created with git init comes with a bunch of example hooks in .git/hooks/. They are named in a pretty self-explanatory fashion such as pre-commit.sample. Go ahead and take a look at them.)

Issues everywhere

Here's a real life example: Imagine a Ruby on Rails app on which a team of developers are working. The code is hosted on GitLab and all the work is coordinated using GitLab issues. In other words: For every commit, there's an associated issue and the issue number acts as a sort of primary key for documentation, time reporting and so forth. This convention has a few advantages, most notably the ability to easily learn more about how, when and by whom features were implemented as well as how this implementation came to be.

As far as Git is concerned, there are two rules:

Feature branches reference the issue ID in their name like 1234_signin_with_passkey.
Every commit message begins with a reference to the issue ID as well, for instance GL-1234: Add webauthn gem.

Putting these references to the respective beginning makes it easy to scan and search for them down the road. Also, GitLab hyperlinks all occurrences of GL-.... with the corresponding issue which greatly improves navigation.

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

This convention works fine until one day, the unavoidable happens and someone commits Fix typo (#123).

Hook me up

First, we need a place inside the repository to store the hook scripts. You might go for .githooks/, but since this example is a Rails app, we'll use lib/git/hooks/.

The first script lib/git/hooks/commit-msg makes sure the commit messages are formatted the way we want:

#!/bin/sh

# Assure the commit message to correctly reference a GitLab issue, CVE
# or GHSA identifier.

regexps=(
    "^GL-\d+: [A-Z0-9]"
    "^CVE-\d{4}-\d+: [A-Z0-9]"
    "^GHSA-[a-z\d]{4}-[a-z\d]{4}-[a-z\d]{4}: [A-Z0-9]"
)

passed=false
for regexp in "${regexps[@]}"; do
  if head -n 1 "$1" | grep -qE "$regexp"; then
    passed=true
  fi
done
if ! $passed; then
  echo "The commit message does not match any of the following constraints:"
  for regexp in "${regexps[@]}"; do
    echo "* $regexp"
  done
  exit 1
fi

This hook script receives a file which contains the commit message as the first argument $1 and compares it against the regular expressions which only allow our GitLab issue prefixes as well as two more prefixes for CVE and GHSA advisories.

(Side note: If you want to allow commit messages without any prefixes as well, you might add something like "^[^:]+$" to the regexps array.)

To make our lives a little easier, we'd like all commits to a properly named branch to get the issue prefix prefilled for us – enter lib/git/hooks/prepare-commit-msg:

#!/bin/sh

# Extract the issue number from the beginning of the branch name (e.g.
# 1234_my_cool_feature) and create a commit message template with the 
# corresponding prefix for GitLab:

prefix="GL"
if ! grep -qv '^#\|^$' "$1"; then
  issue=$(git branch --show-current | grep -oE "\d+[_-]" | grep -oE "\d+")
  if ! [ -z "$issue" ]; then
    echo "$prefix-$issue: $(cat "$1")" >"$1"
  fi
fi

Make sure both scripts are executable!

At their current location, Git won't use them. You could symlink them into .git/hooks/, but there's a better way: Tell Git to look for the hook scripts where you've just put them.

git config core.hooksPath lib/git/hooks

On a Rails app, you might want to add a Rake task lib/tasks/git.rake for this:

namespace :git do
  namespace :hooks do
    desc "Install client side hooks"
    task :install do
      `git config core.hooksPath lib/git/hooks` if Dir.exist? 'lib/git/hooks'
    end
  end
end

Make sure, new developers install the hooks before they start committing by adding the Rake task to the README or the setup script of your project:

rake git:hooks:install

You could even add this line somewhere in the Gemfile to always run this task when the bundle is installed, however, it's a little bit too intrusive for my taste.

And action!

Time to see this at work. Let's create a feature branch and commit some stuff:

git checkout -b 1234_my_awesome_feature
touch foobar.txt
git add .
git commit

The last command opens the preferred editor and shows:

GL-1234: 
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch 1234_my_awesome_feature
# Changes to be committed:
#       new file:   foobar.txt
#

Great, all that's missing is the actual message behind the prefilled GH-1234: and the commit is complete. But unfortunately, it's early morning, the coffee maker is broken and by accident, we edit the message to either:

My awesome commit
GL: My awesome commit
GL-ABCD: My awesome commit
GL-1234 My awesome commit
(...)

The commit-msg hook won't accept any of those and output:

The commit message does not match any of the following constraints:
* ^GL-\d+: [A-Z0-9]
* ^CVE-\d{4}-\d+: [A-Z0-9]
* ^GHSA-[a-z\d]{4}-[a-z\d]{4}-[a-z\d]{4}: [A-Z0-9]

Hook management

This lightweight approach is great for projects which require simple hook scripts only.

In case you wish to run entire pipelines of actions, say a combination of linting, style and license checking along with a required sign-off in the commit message, you should take a look at hook management tools like Lefthook or overcommit.

(Photo by engin akyurt on Unsplash)

10 reasons why 2023 is dead and 2024 is still relevant in 2024

Sven Schwyn — Thu, 07 Mar 2024 14:14:40 +0000

The interweb is full of annoying "X is dead" or "Is Y still relevant?" crap. Reason enough to throw out yet another one finally answering the big questions of our days, curried with just the right buzzword tags.

2023 was the big deal in 2023 and it is still used on old Polaroids and fraudulent checks. But the hype is clearly over.
Everybody is talking about 2024 these days. It made a magnificent entry on the TIOBE index of current years in 2024 and kicked 2023 from the pole position literally overnight.
All big companies have moved on to 2024 including prominent websites like Airbnb, GibHub and Hulu.
The community of people living in 2023 has practically vanished. There's a stubborn crowd of marauders still stuck in 2020, some in 1864 even, but the sharp folks have arrived in 2024 months ago.
2024 is all even, as a whole, digit by digit, horizontal checksum, you name it. This is a huge advantage over the obviously odd 2023.
2024 has one day more than 2023, that's a whopping 0.2747% more year for free.
2023 was released on January 1, 2023 whereas 2024 came out a full year later and therefore 2023 has to be considered out-of-date. Also, there are no more security patches for 2023 which is why all major safety agencies advice against using 2023.
2023 promised us a cage fight to witness Elon Musk's hairdo be bent into shape by this other billionaire weirdo. Yet 2023 failed to deliver miserably.
In summary, the continued relevance of 2024 compared to 2023 can be attributed to ongoing trends, policy impacts, cultural dynamics, global events, and technological advancements that shape the current narrative and influence future trajectories. (Thus spoke ChatGPT, so it must be true.)
Frack, one point short. I'm sure it would have been two points in 2023.

(Photo by taichi nakamura on Unsplash)

Shrink UUIDs with PostgreSQL or Ruby

Sven Schwyn — Fri, 23 Feb 2024 16:17:57 +0000

For a pet project of mine, I'm experimenting with alternatives to the classic SERIAL primary keys which are simple, local and performant. However, you don't want to expose them in URLs because this does away with one layer of protection against forced browsing.

Weak serial booking codes were also at the root of the white hat hack of airline passenger details back in 2016.

Let me share my findings with you, but note: This is not a one-size-fits-all thing, you have to pick your primary keys according to your specific needs.

UUIDv7

An interesting alternative to SERIAL are UUIDv7. They are less performant and more memory hungry given the length, but unless you're dealing with a really huge number of records, the advantages might outweigh these downsides: They are time ordered and therefore INDEX-friendly (unlike fully random UUIDv4), yet their entropy is way large enough for external use and to safely expose them in URLs. (Even more so if some rate limiting is in place to slow down brute force attacks.)

However, UUIDs are the IBAN of IDs, a whopping 36 characters in length and therefore not exactly a healthy diet for your URLs. Say, you have unsafe restful routes with URLs looking as follows:

# Unnested route
https://example.org/users/533

# Nested route
https://example.org/users/533/transactions/743

Now make these routes safe by using UUIDv7 as primary key:

# Unnested route
https://example.org/users/26d45f0c-1fa4-4875-aac7-01a5ec424aac

# Nested route
https://example.org/users/26d45f0c-1fa4-4875-aac7-01a5ec424aac/transactions/b436b1f2-711c-4a50-bb44-4e41acb7e5d6

Boom! Even unnested routes are no longer handy. Is it really necessary for those UUIDs to take up so much space? Not really.

Shrink them UUIDs

It's quite easy to reduce the length of UUIDs by almost 40% from 36 to 22 characters without loosing any data or entropy. Here's how to do it in Ruby:

require 'base64'

def uuid_encode(uuid)
  [uuid.gsub('-', '')].
    pack('H*').
    bytes.
    pack('C*').
    then { Base64.urlsafe_encode64(_1) }.
    slice(0, 22)
end

def uuid_decode(encoded_uuid)
  Base64.urlsafe_decode64(encoded_uuid).
    bytes.
    pack('C*').
    unpack1('H*').
    unpack('a8a4a4a4a12').join('-')
end

(I'm looking forward to Ruby 3.4 which will allow to rewrite the above as then { Base64.urlsafe_encode64(it) }, neat!)

Let's quickly do some roundtrips to check whether this really works:

require 'securerandom'

1000000.times do
  uuid = SecureRandom.uuid
  fail 'mismatch' unless uuid == uuid_decode(uuid_encode(uuid))
end

The resulting URLs are quite a bit shorter now:

# Unnested route
https://example.org/users/JtRfDB-kSHWqxwGl7EJKrA

# Nested route
https://example.org/users/JtRfDB-kSHWqxwGl7EJKrA/transactions/tDax8nEcSlC7RE5BrLfl1g

They still don't win a beauty contest, but if that is what you're after, you'd better use slugs where it's safely possible.

PostgreSQL – take over

You might not want to encode and decode UUIDs on the application layer but do this on the database itself:

CREATE OR REPLACE FUNCTION uuid_encode(uuid uuid) RETURNS text AS $$
  SELECT translate(
    encode(
      decode(
        replace(
          uuid::text,
          '-', ''
        ),
        'hex'
      ),
      'base64'
    ),
    '+/=', '-_'
  );
$$ LANGUAGE sql;

CREATE OR REPLACE FUNCTION uuid_decode(encoded_uuid text) RETURNS uuid AS $$
  SELECT regexp_replace(
    encode(
      decode(
        translate(
          encoded_uuid,
          '-_', '+/'
        ) || '==',
        'base64'
      ),
      'hex'
    ),
    '(.{8})(.{4})(.{4})(.{4})(.{12})', '\1-\2-\3-\4-\5'
  )::uuid
$$ LANGUAGE sql;

Again, let's check whether this works:

DO
$do$
DECLARE
  uuid uuid;
BEGIN
 FOR i IN 1..1000000 LOOP
   uuid := gen_random_uuid();
   IF uuid_decode(uuid_encode(uuid)) != uuid THEN
     RAISE EXCEPTION 'mismatch';
   END IF;
 END LOOP;
END
$do$;

Unfortunately, as of PostgreSQL 16, UUIDv7 are not yet supported out of the box. For the time being, use an extension such as pg_uuidv7 or pg_idkit to generate UUIDv7 e.g. as default primary key when you CREATE new records.

Update December 2024

Still unfortunately, UUIDv7 didn't quite make it to PostgreSQL 17 neither but is en route to be merged before PostgreSQL 18 due in fall 2025. Meanwhile, you can either compile the pg_uuidv7 extension yourself or use one of my packages:

pg_uuidv7 ebuild for Gentoo Linux in my overlay (for PostgreSQL 13 thru 17)
pg_uuidv7 formula for Homebrew (for PostgreSQL versions available on Homebrew)

Update January 2025

UUIDv7 support has been merged and therefore should become available as of PostgreSQL 18 next fall. The function will be called uuidv7().

Update September 2025

With PostgreSQL 18 out, uuidv7() is now available out of the box, no extensions required.

More chit chat on Mastodon

(Photo by Magda Ehlers)

Mirror Android device on desktop screen with scrcpy

Sven Schwyn — Wed, 29 Dec 2021 15:16:05 +0000

A growing number of services such as online banking are accessible on mobile devices only these days, so you may find yourself typing IBANs or reference numbers on tiny on-screen keyboards while your desktop computer keyboard sits right next to it laughing at you.

Stop this, let's mirror the Android device on the desktop screen!

There are quite a few commercial remote control solutions out there, some of which offer limited free tiers once you've registered online. However, particularly when it comes to remote access, I prefer open-source tools which don't require any third party server.

Enter scrcpy, a lightweight CLI tool available for macOS, Linux and Windows. It communicates via ADB which is preinstalled on every Android device and doesn't require it to be rooted.

Prep the Android device

On the Android device, open developer options and enable «Android debugging (ADB)». (In case you don't find the developer options, you have to enable those beforehand.)

ADB requires a USB connection by default which is secure, but not very handy. If and only if you are on a secure private network, you may use a TCP/IP connection instead, say your home wifi network. Check available widgets, you might find one called «ADB over network» to easily switch this feature on and off.

Just to make sure you've understood the risks: Never enable «ADB over network» on insecure public networks!

Install scrcpy on the desktop computer

The following is for Macs, but you find instructions for Linux or Windows on the scrcpy README.

Unless already present, install Homebrew on your Mac. Then open a terminal and install scrcpy as well as the offical Android development tools.

brew install scrcpy
brew install android-platform-tools

You might also want to set an aliases in order not having to memorize scrcpy and it's options. Here's the alias when using a USB connection:

# macOS 12 or newer
echo 'alias android="scrcpy --stay-awake"' >>~/.zshrc
source ~/.zshrc

# macOS 11 or older
echo 'alias android="scrcpy --stay-awake"' >>~/.bash_profile
source ~/.bash_profile

When using a TCP/IP connection, you have to make sure your Android device always gets the same IP address assigned by the router. The following assumes the device on IP 192.168.1.10:

# macOS 12 or newer
echo 'alias android="scrcpy --tcpip=192.168.1.10 --bit-rate 2M --max-size 800 --stay-awake"' >>~/.zshrc
source ~/.zshrc

# macOS 11 or older
echo 'alias android="scrcpy --tcpip=192.168.1.10 --bit-rate 2M --max-size 800 --stay-awake"' >>~/.bash_profile
source ~/.bash_profile

Spieglein, Spieglein

Time to mirror! Either connect the Android device to the computer or enable «ADB over network», then open a terminal on the Mac and type:

android

A window should pop up and mirror the Android screen. You can mouse around, type input, even copy/paste as if it were just another application running. 🎉

Given the multitude of different Android devices, this might not work at the first attempt. You find troubleshooting hints in the scrcpy README.

(Photo by Rishabh Dharmani on Unsplash)

Command aliases for Ruby debug

Sven Schwyn — Mon, 13 Dec 2021 21:01:03 +0000

After years with Pry, there's a new old kid on the block now: debug.rb >=1.0.0 – all new, shiny and ready for Ruby 3.

One thing I miss though is the ability to create command aliases.

To quickly get out of the debugger, typing «exit-program» involves too many hands for my taste, I prefer something quick like «eee» instead. Pry lets you create such command aliases in ~/.pryrc:

Pry.config.commands.alias_command "eee", "exit-program"
Pry.config.commands.alias_command "ee", "exit"

Typing «kill!» or its shorter twin «k!» with debug.rb is no fun either. Here's a quick and dirty monkey patch to do a similar trick in ~/.rdbgrc.rb:

module DEBUGGER__
  class Session
    COMMAND_ALIASES = {
      'ee' => 'quit!',
      'eee' => 'kill!'
    }.freeze

    alias_method :original_process_command, :process_command
    def process_command line
      original_process_command COMMAND_ALIASES.fetch(line, line)
    end
  end
end

Happy hammering your "e" key!

Photo by Jørgen Håland on Unsplash

Keyoxide proof

Sven Schwyn — Sun, 28 Nov 2021 15:49:47 +0000

This is an OpenPGP proof that connects my OpenPGP key to this dev.to account. For details check out https://keyoxide.org/guides/openpgp-proofs

[Verifying my OpenPGP key: openpgp4fpr:d0654ab99d5016af7c4e06bff72b2e4be8d06a87]