Stanislav (Stas) Katkov

Mutation testing in the age of LLMs

Wed, 01 Jul 2026 09:38:00 +0000

The last conference I attended was Wroclaw RB. The conference had workshops in the first part, and I was really excited about the mutation testing workshop.

Google, in one of their research papers, claimed that mutation testing might have prevented 7 out of 10 production accidents if this testing practice was widely used.

“Mutants are coupled with 70% of high-priority bugs, for which mutation testing would have reported a live, fault-coupled mutant on the bug-introducing change.”

If you are a small business owner like me, you will take that edge over competitors any time.

My experience with mutation testing in other languages has been rather unstable. It felt like a great idea, and you could surface some improvements, but it was not something that I could run reliably on CI or even locally. It was even harder to sell the idea of 100% mutant coverage to the team in the pre-LLM era. A lot of teams struggled with automated tests in general and were very far away from such a tough metric.

But the author of the mutant gem, Markus, has been using mutation testing in production for years. And there have been a lot of rumors about Ruby teams that practice mutation testing with his gem as well.

It felt like, in the age of LLMs, running full mutation coverage for projects should be easier. And Markus’s workshop proved it.

At first we tried mutation testing manually, and after that did the same, but with LLMs. The LLM was capable of doing all the reasoning to effectively kill mutants, with very little input from my side.

I came home energized, with a feeling that I had found a magic pill for my LLM-powered development. I relied on LLMs a lot, but never trusted their output. I meticulously went over each line they generated, and my main responsibility was to delete as much code as possible (and I removed a lot).

Markus showed us toy examples. But how would it work on real Ruby projects? I had 3 open source projects to test this on before making a “go or no-go” decision for commercial projects.

Mutating OSS

My side-project heavily depends on 3 open-source Ruby projects, so I picked them to experiment with the mutant gem.

webhukhs gem

Here is the PR: https://github.com/skatkov/webhukhs/pull/13

The webhukhs gem is a webhooks processing engine for Rails. This is a very stable gem that had already been tested on multiple projects.

I mostly expected to see increased test coverage. But I was surprised to find a lot of great simplifications that I had completely missed.

.is_a?() can return true for an instance of a class or any ancestor. instance_of?() will only return true for an exact class match. So in my case, instance_of? is more precise.
Type casting was unneeded in a lot of places (e.g. .to_s or .to_json).
.force_encoding(Encoding::BINARY) was replaced with the simpler .b. I didn’t like this particular simplification. I prefer the explicit version. But I guess it’s very easy to mess up attributes here? So I went along with it, but it would be awesome if such cases could be configured.
hash[:key] was replaced with hash.fetch(:key). This is what I do myself all the time, but I completely missed one case.
rescue didn’t require assignment to the e variable. Great one, fewer variable allocations.
Rails.error.report(e, handled: true, severity: :error) was simplified to Rails.error.report(e, severity: :error). handled: true is a default value, so there was no need to provide this attribute.

Even though we didn’t surface any bugs, it still felt like a good enough improvement! So I decided to proceed further and see if mutant would bring more benefit in other projects.

yard-markdown gem

Here is the PR: https://github.com/skatkov/yard-markdown/pull/33 (there are more PRs that followed after)

Contrary to the previous polished gem, this was hacked together to “just work”. A proof of concept, in a way. There was no design or architecture; most of the code was in a single file that came with a template and glue code that made it work together.

There could be so many data permutations that this plugin could break in various unexpected ways. And I already knew that there were at least two bugs in this gem, but even with decent tests it was scary to touch. Would mutant find them?

In my LLM prompt, I did say: “It would be great if the code had better organization and this gem became easier to maintain long term.” I was not expecting much, but tried to be upfront about the desired results.

And I lost track of all the small code simplifications that this brought. The LLM, with mutant assistance, stopped only twice to ask for my help. In both cases it was because it had found a logic bug. The LLM found all the bugs I knew about.

Not only that, the code was neatly organized. It was more maintainable. I was not afraid to touch it anymore. I threw in yard-lint to improve code comments! This was a natural “oh, shit, what just happened?” moment.

I could not believe my own eyes: mutant had surfaced bugs and the LLM had properly signaled that something funny was going on. This was a success! I couldn’t wait to onboard another similar project and couldn’t go to sleep without doing that.

rdoc-markdown gem

Here is a PR: https://github.com/skatkov/rdoc-markdown/pull/58 (this had multiple follow-up PRs)

While the code for this gem was rather simple, conversion to markdown is rather hacky: HTML is getting converted into markdown. This entire thing is riddled with bugs, but I currently see no other way to integrate with rdoc and achieve a more stable solution.

On some gems this plugin just threw errors…

Mutant caught around 8 bugs and I managed to resolve 6. There are no gems that just fail after 100% coverage anymore. Yet there are more bugs left… mutant made a lot of them visible (but not all, though).

Unfortunately, there is not much that I can do in the rdoc-markdown gem itself to resolve all issues. RDoc itself requires more work.

At this stage I was sold, and immediately wrote to Markus that I needed that license.

Lessons learned

I have on-boarded 6 Ruby projects into mutation testing at the time of writing. It roughly took me two days to onboard each project into mutation testing, but with bigger rails project it took my couple of weeks of gradual conversion.

Mutant is now a staple of my workflow when I deal with Ruby projects. It helps with LLM fatigue. I still look into code LLM’s produce, but more to get a feeling for what architecture we’re building here.

In the pre-LLM era there was an argument that the costs of maintaining 100% mutant test coverage were too high. But with LLMs, this argument is completely void. LLMs can make the right call about where to simplify and where to add more tests. In some hairy spots, the LLM gives up, and this is where I pay attention, as this is most likely a bug.
At first, the LLM powered by mutant went overboard with adding tests. A lot of new tests felt repetitive and excessive. I still have not found a perfect way to deal with it to my satisfaction, but there are a couple of ways to improve this:
- minitest/rails seemed too lax with assertions. The fact that nil could be typecasted into a false value allowed a lot of live mutations that needed killing with additional tests. As it turns out, minitest-strict solves exactly that problem and allowed me to eliminate a lot of new tests.
- I can ask the LLM to attempt to delete some repetitive tests, while keeping a close eye on coverage.
- Maybe in the future we can have mutation testing for non-production code?
I got a little anxious seeing so much existing production code changed by LLMs. They were removing guard clauses, some checks… “this surely will backfire somehow”, I thought to myself. But I haven’t seen any new bugs introduced after mutant-powered refactoring did its job. ZERO issues!
Emboldened by the success in Ruby, I tried mutation testing in other languages. And I understood that writing a generic mutation testing framework is not that hard, but making it usable is really hard. It’s also computationally heavy. Incremental mutation testing of only code that is being changed is a killer feature of the mutant gem. So that $30/month fee for the mutant gem? Worth it! I don’t curse at every random error and don’t have the urge to fix the mutation testing framework itself.
As a web developer, I have never really seen all my CPUs work to their full potential. The mutant gem changes that, to the point that the browser started fighting for resources. Parallelization of agents with mutant has to be done carefully; one has to be sure not to execute multiple mutants at the same time. Getting a beefy server and running mutant there seems like a good idea that I haven’t tried so far. Relying on GitHub Actions is not enough now either.
Sometimes I’m in prototyping mode, trying to figure out whether a library or approach is workable, and in that moment mutant slows everything down and derails the entire process. In my head, “mutant” is a final polish step, and to draw this distinction I’ve created a “prototype” mode in my opencode, with explicit instructions not to execute any mutation testing.
I’ve been following Markus, the mutant gem author, and his work for some time. He is one of the original developer thinkers, not someone who just blindly follows “best practices”. And he goes out of his way to provide support and share his experience. It was an enriching experience for me personally just to have a couple of random chats with him. I’m standing here and questioning a lot of my personal choices as a result (and hopefully that makes me a slightly better developer now).

As a conclusion, I wanted to share a single thought with the world. No matter what kind of language you’re dealing with, take a day off and try a mutation testing framework.

I have continued my experiments with advanced testing approaches: I’m experimenting with fuzz testing and property testing. Especially bombadil’s experimental support for TUIs makes me excited. But let’s leave this part for future articles.

Signing and notarizing a Mac app on Linux

Thu, 25 Jun 2026 17:04:00 +0000

I had to sign and notarize the Posh TUI Mac app. The problem is that our household moved away from Apple. My last MacBook (Intel-based) was converted into an Omarchy machine for my son. But all the documentation assumed access to a MacBook and Keychain.app.

So what should I do? Rent a Mac in the cloud? Borrow someone’s MacBook for a couple of hours? There is nothing inherently Apple-specific about signing apps.

According to the GoReleaser documentation, these things are required for signing and notarization.

MACOS_SIGN_P12 - base64-encoded Developer ID Application .p12
MACOS_SIGN_PASSWORD - password for the .p12
MACOS_NOTARY_KEY - base64-encoded App Store Connect .p8
MACOS_NOTARY_KEY_ID - App Store Connect key ID
MACOS_NOTARY_ISSUER_ID - App Store Connect issuer UUID

Here’s how to get all of these on Linux (Fedora, in my case). This guide assumes that you already have an Apple Developer Account and have paid the $99/year fee.

Developer ID Application (aka `.p12`)

The first stage is application signing, and it’s the tricky part. This requires some OpenSSL kung fu to get all the certificates and keys right.

1. Generate a private key

Do this if you don’t have one already. Store it safely.

openssl genrsa -out mykey.key 2048

2. Generate a Certificate Signing Request (CSR)

After this operation, you will have a CertificateSigningRequest.certSigningRequest file.

openssl req -new -key mykey.key -out CertificateSigningRequest.certSigningRequest -subj "/emailAddress=krooni@skatkov.com/CN=Stanislav Katkov/C=NL"

3. Upload the CSR to Apple’s Developer Portal

Go to your Apple Developer account and create a new certificate.

This is where you should upload that CertificateSigningRequest.certSigningRequest file. Apple website will give you a .cer file in return: the actual certificate, signed by Apple.

Steps to Create the `.p12`

Convert Apple’s .cer file (DER format) to PEM format:

openssl x509 -inform DER -in developerID_application.cer -out developer_id.pem

Combine the certificate and your private key into a .p12 file:

openssl pkcs12 -export -out Certificates.p12 \
  -inkey mykey.key \
  -in developer_id.pem

During export, OpenSSL will ask you to set a password for the .p12 certificate. You can skip it, but I suggest setting one. Store it in your password manager.

Now we have Certificates.p12 certificate on our hands. And we can proceed to next step.

Getting the `.p8` key

Gathering everything required for notarization is the easiest part. It requires downloading one file and copying a couple of values.

Go to the App Store Connect portal and log in
After logging in, open the Users and Access section, then click the Integrations tab
On the Integrations page, you’ll find the Issuer ID and the option to create a new API key. Click the + button to create one
The new key needs to have at least the App Manager access level
Click Download API Key to download the key

It will be saved as a .p8 file named AuthKey_[key_id]. Besides this .p8 key, we need 2 more things from this page:

Item	Where to find it
Key ID	Shown in the key list
Issuer ID	Shown above the “Active” table

Assembling all of this together

Now for the signing process.

In my case, I had to make 3 tools work together.

GoReleaser

Your .goreleaser.yaml should look like this:

notarize:
  macos:
    - enabled: '{{ isEnvSet "MACOS_SIGN_P12" }}'
      sign:
        certificate: "{{.Env.MACOS_SIGN_P12}}"  # base64 encoded .p12
        password: "{{.Env.MACOS_SIGN_PASSWORD}}"
      notarize:
        issuer_id: "{{.Env.MACOS_NOTARY_ISSUER_ID}}"
        key_id: "{{.Env.MACOS_NOTARY_KEY_ID}}"
        key: "{{.Env.MACOS_NOTARY_KEY}}"  # base64 encoded .p8

GitHub Actions

The same ENV variables need to be added as secrets to your GitHub repository. With the following small change, you can expose them as ENV variables for GoReleaser.

jobs:
  goreleaser:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: goreleaser/goreleaser-action@v7
        with:
          distribution: goreleaser
          version: "~> v2"
          args: release --clean
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          MACOS_SIGN_P12: ${{ secrets.MACOS_SIGN_P12 }}
          MACOS_SIGN_PASSWORD: ${{ secrets.MACOS_SIGN_PASSWORD }}
          MACOS_NOTARY_KEY: ${{ secrets.MACOS_NOTARY_KEY }}
          MACOS_NOTARY_KEY_ID: ${{ secrets.MACOS_NOTARY_KEY_ID }}
          MACOS_NOTARY_ISSUER_ID: ${{ secrets.MACOS_NOTARY_ISSUER_ID }}

Mise

For a local release, put the same values in an uncommitted mise.local.toml:

redactions = ["MACOS_*"]

[env]
MACOS_SIGN_P12 = "/absolute/path/to/Certificates.p12"
MACOS_SIGN_PASSWORD = "p12-password"
MACOS_NOTARY_KEY = "/absolute/path/to/ApiKey_AAABBBCCC.p8"
MACOS_NOTARY_KEY_ID = "AAABBBCCC"
MACOS_NOTARY_ISSUER_ID = "issuer-uuid"

Testing

Testing the entire process without issuing a new release is easy with the --snapshot attribute for goreleaser release command. It skips many steps, like publishing and announcements.

goreleaser release --clean --snapshot

The first notarization process took a lot of time (more than 12 hours), so I installed quill locally to monitor the submission status.

mise exec -- sh -c 'quill submission status <submission-id> --notary-issuer "$MACOS_NOTARY_ISSUER_ID" --notary-key-id "$MACOS_NOTARY_KEY_ID" --notary-key "$MACOS_NOTARY_KEY"'

Once the status changes from Pending to Accepted, you know that everything is good to go.

Closing notes

Everyone tells me that there are so many things you can’t do on Linux. But I’ve successfully dodged the need to buy another Windows/macOS machine for the last 8 years. This is another “Nope, Linux is enough” post.

Feel free to try the latest release of POSH TUI as proof that it’s possible to sign and notarize a macOS app without touching an Apple laptop.

Let it rip

Sat, 14 Feb 2026 19:37:00 +0000

Huge LLM user here. I didn’t become one a couple of months ago — I’ve been experimenting with LLMs for a while. But it’s hard to find the courage to write about this experience. Every couple of weeks the LLM-powered workflow shifts — people keep coming up with great ways to use it.

One thing that never changed for me was that an LLM was only a handy assistant, nothing more than that. But this time, I gave the LLM a boring maintenance loop and it actually shipped a lot meaningful improvements without any guidance at all.

(yard|rdoc)-markdown gems

This year, all my time has been going towards one project — Posh TUI.

A Markdown renderer is a big part of an application like this. I’m using the glamour library from the Charm team. Thank god I don’t have to figure out how to render Markdown in a terminal — it’s a crazy complicated problem.

But I do have to figure out how to convert Ruby source code into Markdown documentation. The main issue is that it has to be done reliably. Quick workarounds don’t cut it here. So that led me to write a couple of libraries — yard-markdown and rdoc-markdown — to make that possible.

It seems like I picked the right approach. But to make it work, I went into this loop to generate → compare → tweak → test → repeat (500x) and got tired of it. The libraries got stuck in a “it doesn’t break; looks legit for now” state.

But this is part of the core experience for users — these libraries matter. I just didn’t have enough drive to solve it once and for all.

Let it rip

One weekend I asked an LLM to work on the rdoc-markdown gem. But this time my prompt started with: “Don’t ask any questions. Make your best guess and proceed without assistance.” The plan was to run this session in “yolo” mode.

I laid out all the context:

How to generate output
That the output should be as close to HTML as possible
That there might be bugs
Which gems it might use as good test subjects

After that was out of the way, I suggested it might be a good idea to do this in a loop.

With that, I made sure my laptop wouldn’t automatically go to sleep. And I let it rip.

Pupil outdid its master

It took it a couple of hours to do all this boring, repetitive work. I checked on it a couple of times before going to sleep, but I never assisted. There wasn’t a specific goal — it used its best judgment and just kept going.

In the morning, the results were in.

It produced decent Markdown documentation for Rails, then for Minitest, and then for Ruby itself. I couldn’t believe my eyes — it squashed all the bugs I knew about. More than that, it looked great.

Of course, I couldn’t let this slide — I jumped into the code and found some bugs. Now you see who’s the boss around here?

Jokes aside: I ran a similar procedure on the yard-markdown gem the next evening, and the results were similarly good.

Now I’m sitting here relieved that I probably saved myself at least a month of part-time work. But at the same time I’m wondering: would I have found enough motivation to do the same tedious job at the same level of execution? I’m not sure I would.

I didn’t even bother guiding anything in this process. And for a brief moment, the compute became its own master and executed the work the way it saw fit. Bravo, young padawan.

Warning about deprecations in Ruby

Fri, 17 Oct 2025 22:44:00 +0000

I’ve been looking into ways how libraries and rails engines communicate deprecation warnings and found couple of surprising things.

Everyone working with Rails probably heard or seen ActiveSupport::Deprecation in action. But what about gems that don’t depend on any rails dependencies? Kernel.warn might surprise you here.

ActiveSupport::Deprecation

Rails offers a no thrills way to emit deprecation warnings, that everyone already knows about.

Before Rails 7.1 it would look like this:

ActiveSupport::Deprecation.warn("Method will be removed in next version")

# or
deprecator = ActiveSupport::Deprecation.new("2.0", "MyGem")
deprecator.warn("Method will be removed in next version")

But starting with Rails 7.1 explicit deprecators registry became a thing. So things became even simpler.

Rails.deprecator.warn("Method will be removed in next version")

# or for specific gems

Rails.deprecators[:my_gem].warn("Method will be removed in next version")

How these deprecations are communicated can be configured with config.active_support.deprecation setting .

Value	Result
:raise	Raise ActiveSupport::DeprecationException
:stderr	Logs all deprecation warnings to `$stderr`
:log	Logs all deprecation warnings to Rails.logger
:notify	Use ActiveSupport::Notifications to notify `deprecation.rails`
:report	Use ActiveSupport::ErrorReporter to report deprecations
:silence	Do nothing

There is also a way to include stack trace with every warning if you enable debug mode.

Rails.application.deprecators.debug = true

Everything seems pretty clear and simple here. But what if you don’t depend on active support?

Kernel.warn

Turns out, that Kernel.warn is not just a generic method to emit warnings. Kernel.warn doubles down as a way to communicate deprecation’s, experimental features or performance improvements.

There are two downsides though:

It’s not very well documented, so hardly anyone knows.
Deprecation warnings are silenced by default

But here is way to emit a deprecation warning:

warn("Method is deprecated", category: :deprecated)

Problem is that nobody is likely to be listening. Since default values for each category are as follows:

Warning[:deprecated] # => false
Warning[:experimental] # => true
Warning[:performance] # => false

Warning and performance categories are silenced by default. But off course this could be changed by setting Warning[:deprecated] = true or using -W argument in RUBYOPTS.

export RUBYOPT="-W1:deprecated"

Or you can ask ruby to be more verbose and this will enable all warning categories:

export RUBYOPTS="-W2"

I’m hunting for deprecation’s, but performance improvement warnings can give a lot of nice hints and are worth exploring too.

Ordering Estonian ID on Linux!

Fri, 26 Sep 2025 16:09:00 +0000

I’m an Estonian passport holder, not living in Estonia for a long time. I don’t get to interact with Estonian government services much, even though I kind of miss the simplicity of that interaction. I have never in my life had to run around different Estonian government buildings to get things resolved. Things are always resolved digitally from the comfort of my home.

This is something you don’t appreciate until you travel around and see how far ahead Estonia is in its digitization, even compared to richer countries like the Netherlands. And don’t get me started on countries like Thailand, where there’s an entire service industry that helps you deal with the annoyances of government-required paperwork—it’s a lucrative business for a reason.

But let’s get back to Estonia and the main reason I’m writing this blog post. I have to change my passport and ID every 5 years—it’s possible to do digitally, but only if one manages to securely identify themselves.

In my case, the only option is the ID card. This requires a special device to read the smart card. As a long-time Linux user, I often scratch my head figuring out how to make such devices work, since Linux support is rarely advertised and the documentation has zero information related to Linux.

But I wanted to avoid wasting two days traveling to The Hague (to request a new document and to actually receive it) and request a new ID card online.

So, how do you read an Estonian ID card on a Manjaro-powered Linux machine? The id.ee website offers a basic manual on how to proceed. They claim to support Linux, but most of their guides are focused on Debian-based distros (primarily Ubuntu), and I found that some steps are missing.

Getting a smart card reader to work

I don’t know much about smart card readers and the differences between them. Most readers I’ve used worked just fine on all Linux machines, even if they don’t market their Linux support.

After a quick search on Amazon, I ordered a Lindy USB 2.0 Smart Card Reader. Linux support is not advertised, but I was pretty sure it would work (or else I’d just return it).

Once I plugged it in, the lights came on, which was a good sign. DigiDoc4 client is used to read data from ID cards. This package is available through Flatpak on most Linux distributions.

But once I opened the DigiDoc client, I was met with a surprising error.

“The PSCS service, required for using the ID-card, is not working”

Issues with the ID-card reader page gave me a useful tip, that I just need to enable pcscd server via systemctl.

systemctl enable pcscd.socket  
sudo systemctl start pcscd.socket

Now the error was gone, but DigiDoc couldn’t identify my card reader and showed another interesting error.

“No card readers found”

The smart card reader was definitely there—it was blinking with red/blue lights, and the lsusb command actually showed the device in the list.

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID
Bus 001 Device 003: ID 0489:e0d8 Foxconn / Hon Hai Bluetooth 5.2 Adapter [MediaTek MT7922]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 13d3:5293 IMC Networks Integrated Camera
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 007 Device 008: ID 0bda:0165 Realtek Semiconductor Corp. Smart Card Reader Interface
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

It turned out I was missing some packages that would allow the DigiDoc client to find and use the smart card reader.

sudo pacman -S ccid opensc libp11 engine_pkcs11

At this point, restart the DigiDoc4 client, and personal data should show up (I’m not adding any screenshots here, as it’s private). This ensures that the card reader is operational and the ID card is not damaged and can be used.

But the goal here is to sign/verify things through the browser so I can request a new document online.

Integrating the card reader with Firefox

I’m using Firefox for this example, and according to the manual from id.ee, it requires just two extensions to work:

But nothing worked. The police website told me that my software was outdated and I needed to update.

The old web authorization method for smart cards had a lot of stability issues in the past. So it turns out that now Estonian government services rely on web-eid, and it requires a native client called web-eid on the machine for authorization to work.

First, import certificates to ensure we’re using the correct source:

gpg --keyserver keyserver.ubuntu.com --recv-keys 1282B0F8809D0DC632C85A3F86B611CE24492160
gpg --keyserver keyserver.ubuntu.com --recv-keys D1EBC666EFCBFBD3CFC2EBAA90C0B5E75C3B195D

Then, install the native client and the WebExtension wrapper that communicates with the browser:

sudo pamac -S web-eid-native web-eid-firefox

The web-eid.eu page has a way to test that both signing and authorization work as expected—and it did.

Conclusion

As often happens with documentation, id.ee has slightly outdated documentation and forgot to mention a couple of crucial steps. It’s not surprising because they have to maintain documentation in three different languages—easy to forget things.

This small manual isn’t that interesting for most people around the globe, just for the million or so Estonians who have to use eGovernment services. But I’m sure I’ll be thankful for publishing this after 5 years (by the time I need to change some documents again).

From zsh to fish shell

Wed, 30 Jul 2025 12:56:00 +0000

Always wanted to move from zsh to fish, but never found a good excuse to spend time on that. Recently a new motherboard for the laptop arrived, this event created a need to wipe entire system clean so we can start over.

That’s a good excuse not to install zsh and use fish!

Why

Often people complain that zsh takes a while to boot for every new terminal. This is indeed annoying, but not zsh’s fault. The main culprit here is widely used oh-my-zsh , but prezto solves this issue for good. And I’ve been using it for years!

My main complaints have been about other, smaller issues:

While prezto is great, the installation and update process is not enjoyable. I’ve gone through the setup at least 10 times in the last 3 years, and I still mess something up at first try.
ZSH’s strict attributes parser has forced me to ‘quote’ and escape some things better. It’s a well-known quirk at this point, but it still gets on my nerves every time. Most of these “zsh bites me when I forget to quote” problems either do not exist in fish or are greatly reduced, because fish’s grammar is simpler: no history expansion, no glob qualifiers, no K-style extended globs, no parameter flags, no arithmetic in $((…)), etc.
Configuration for bash and zsh is hectic and scattered across multiple files (~/.bashrc, ~/.bash_profile, ~/.zshrc, etc). There are multitudes of ways to organize and maintain these better, non of those approaches left me satisfied. All fish config files could be found in ~/.config/fish/ folder, that’s a great default!

Nothing fish-y here

Fish has been a blast so far!

It comes with syntax highlighting, suggestions, and completions based on man pages—out of the box, no plugins needed. But we can cherry-pick the plugins if anything extra was needed.

So I decided to make a default shell right away. On Fedora this takes exactly three commands to accomplish.

sudo dnf install fish
sudo dnf install util-linux-user # fedora needs this package to install default shells.
chsh -s /usr/bin/fish

But things only get better from here with just couple of more plugins. And fish comes with a awesome package manager called - Fisher: A proper package manager, can you imagine that?

It will get handy, so let’s install Fisher without any further ado.

curl -sL https://raw.githubusercontent.com/jorgebucaran/fisher/main/functions/fisher.fish | source && fisher install jorgebucaran/fisher

Powerline prompt

One of the main selling features of zsh is a git-aware powerline prompt. Fish comes with a pretty decent port of this theme.

fisher oh-my-fish/theme-bobthefish

Every Nord theme fanatic will need to insert one line into a ~/.config/fish/config.fish.

set -g theme_color_scheme nord

Directory jumper

cd is the most popular command used in a terminal by far, so since forever I relied on rupa/z to jump through directories. There are modern alternatives, but original has never failed me.

But rupa/z was a bit of a pain to get working during setup. So fish port of Z and fisher package manager made this a breeze!

fisher install jethrokuan/z

fzf/history search

fish comes with built-in history search functionality available through ctrl+r. This would previously require a plugin in zsh, but this is built in. Adding fzf to this turns this already powerful feature into an overpowered one.

fisher install PatrickF1/fzf.fish

Conclusion

All in all - Fish is a great improvement over ZSH. It might not be worth it for people that don’t touch terminal as much as I do. But for me, it’s a small productivity boost that keeps on giving every day.

Software License management with Polar.sh

Sun, 11 May 2025 16:38:00 +0000

This article would have been incredibly helpful to me just a month ago—so here it is, primarily for other developers who, like me, don’t usually write software that’s meant to run in non-server environments.

I just introduced licenses to one of my apps—DevTUI. There’s another app that suffers from my code, PoshTUI, and it might require something similar soon. I suspect all of this will come in handy again in the future.

Brief idea

Not all licensing features have been rolled out yet, so let me briefly explain the overall vision.

DevTUI will be available to everyone as a free product, with no limitations on functionality. However, it will include a nagging popup prompting users to support further development. Users can remove this nag screen by paying a (reasonable) one-time fee.

The inspiration for this payment model comes from Postico and Sublime Text — two products I personally support and admire.

Since DevTUI doesn’t incur any recurring costs, I’m okay with people using it for free. That said, I still want to encourage users to contribute financially to the project rather than relying on the usual “begging for open source funding” approach.

Requirements for licensing solution

Starting out, I only knew what needed to be built: a licensing solution for a one-time payment product. A solution should support the following requirements:

Ability to issue free licenses to early supporters of PoshTUI
Ability to limit each license to three machines (or less)
Allow customers to manage their licenses without a need to contact support(e.g. deactivate licenses or view receipts)
Should work offline; license validation should not run every time the app starts

Licensing Server

I’m using Polar.sh as my payment and licensing provider. I’m skipping the part about how I ended up with them—no interest in badmouthing any competitors.

Rolling your own solution on top of Stripe is also possible. But that wasn’t an option worth pursuing for me. A 4% cut of future revenue seemed like a fair trade-off to avoid dealing with payment handling and license infrastructure.

Polar team has been incredibly helpful. When I first contacted them, they didn’t even have a Go SDK, but they published one within two days. They also responded with useful tips and shipped fixes—again, all within 48 hours of my initial email.

Polar.sh provides me with all the server side niceties.

Offer a way to define a product that can be paid one time
There is also Discounts for those early supporters and friends
Customer portal
Checkout links for a product, even one with a 100% discount

But the client-side implementation is up to me.

License Activation

The app can do three license related actions - active, validate and deactivate. All these action are currently implemented in a CLI interface.

Commands for activating, validating, and deactivating licenses  
  
Usage:  
 devtui license [command]  
  
Available Commands:  
 activate    Activate a license  
 deactivate  Deactivate a license  
 validate    Validate a license  
  

But I expect that most users will probably invoke only one command - activate.

Activate

This is how user can activate a license

devtui license activate --key=DEVTUI-2CA57A34-E191-4290-A394-XXXXXX

I’m intentionally not using any ENV variables — this would require an additional library, and I don’t want users polluting their .zshrc or .bashrc with extra variables.

After activation, the key and related info are stored in a license.json file.

During activation with an API call to Polar.sh i’m passing a “conditions” field. In our case, we use the MAC address to associate the license with a specific machine. The licensing server enforces a maximum of 3 machines per license.

Validate

This action uses the license.json file created during activation. While the CLI command simply checks that the license is active, this validation logic is also embedded directly in the app.

Here’s a rough outline of the validation logic:

It’s checking that hash sum matches expectations
If it doesn’t match -> We re-validate license with server
If it does match -> We check if it’s time to check license with a server.
During a license check with server, if MAC address is not similar to one we used during activation - validation will fail. This would prevent people from just moving license.json file to another machine.

Software attempts to validate license with a server every week, this time frame is completely arbitrary.

Deactivate

This also uses the license.json file created during activation.

While it’s already possible to deactivate a license via the customer portal, having it available in the CLI felt important. Two use cases come to mind:

Running the app in CI environments where machines constantly get recycled
Switching from one machine to another

Identifying a Machine

To my knowledge, most software uniquely identify a machine by its MAC address. It’s important to try and find the physical, manufacturer-assigned MAC address, use it during license activation, and later rely on it during validation.

However, not all MAC addresses are created equal. There are also Locally Administered Addresses (LAAs), these are not the same because they could be:

Manually assigned by a network administrator
Often used in virtual machines
Common in network virtualization scenarios

It’s possible to identify those by checking the second least significant bit of the first octet:

If the bit is 1, it’s locally administered
If it’s 0, it’s universally administered

Examples:

02:00:00:00:00:00 → locally administered
00:1A:2B:3C:4D:5E → universally administered

License File

We use the github.com/adrg/xdg library to determine where to store the license file.

This library implements the XDG Base Directory and XDG User Directory specifications, offering a standard mechanism for storing application state, data, or configuration across multiple OSes—Windows, Linux, Plan 9, and macOS.

In the app’s case, we rely on XDG_DATA_HOME, or fallbacks as per OS:

Unix	macOS	Plan 9	Windows
~/.local/share	~/Library/Application Support	$home/lib	LocalAppData

Example ‘license.json’:

{  
 "hash": "7394991a704a054096f4484d8a19f9ac66e3e8c98b68603652feadc785a364f2",  
 "license_key_id": "DEVTUI-2CA57A34-E191-4290-A394-XXXXXX",  
 "activation_id": "2ee71107-2ecb-4172-aff7-ceaa6b2f7cef",  
 "next_check_time": "2025-05-12T23:18:12.7724912+02:00",  
 "last_verified_at": "2025-05-05T23:18:12.772488825+02:00"
}

The hash is generated from multiple values and is used to verify that the license data hasn’t been tampered with. If the hash doesn’t match, the app treats the license as invalid.

I won’t go into the full details of what goes into the hash, but in general:

MAC address
License key
Activation time
Next check timestamp
A salt value (random string)

This mechanism isn’t hacker-proof, but the effort required to crack it should outweigh the $40 one-time price tag.

Final notes

This is my first time implementing client-side license logic for an app, so I’ve probably missed some edge cases. But if anyone has some feedback or recommendations, please reach out.

Strange thing about happiness.

Thu, 28 Nov 2024 13:43:00 +0000

Once, my mom showed me a video where I was having water fun with my kid after I finished my wake boarding session. My mother captured a joyful moment, but guy on a video was shirtless, which saddened the video for me. That guy on a video looked visibly fat (over 100 kilos) with hanging breasts.

It was clear - that “guy” had let himself loose. Even though, nobody ever said it out loud. That guy decided that he has higher standards for himself and body shape needed to be rectified.

Wake boarding is definitely fun, but it’s not enough in Dutch climate. Luckily, I found a kickboxing gym near by house, and trainer seemed really good. I already had experience with muay thai before, and knew that dutch kickboxing was dominating. So the dutch kickboxing journey started.

For the first month, I would vomit from the intensity of the workouts. After a month I became a bit more confident and started participating in sparing sessions. It was not always light and my body already was not as conditioned - so injuries started creeping in into my day to day life. It is intense, and I came back exhausted - couldn’t do anything else but sleep. (bummer, if you planned to work on a side-project that evening)

It was only after about 8 months that I could get through workouts without major upheavals. It became a routine - train, come home, take a shower, and continue with my daily activities. Injuries are also a thing of the past, and even bruises hardly appear anymore.

My weight is now 97 kg, much less than before. BMI is on the border of normal. Muscles and ABS could be spotted on my body once again. Kickboxing have become my outlet - when I feel bad, I go straight to the gym. People are already worried when I don’t come for a long time. How can I not go now and let the guys down?

I found my sport in the Netherlands, and of course, wake boarding when it’s warm. My son was inspired and he goes twice a week to same kickboxing gym. Those bullies should be really careful around my son now - he can already kick ass.

Sport really increases happiness levels. And a lot of water.

Coworking in Eindhoven

Fri, 22 Nov 2024 11:26:00 +0000

I’m permanently based in Eindhoven these days. We tried to make nomad life work, but decided not to pursue this lifestyle any longer. I’m able to work remotely and still do, but:

kid needs a stable school and circle of friends around him
wife can’t sit straight for hours at a computer, so she needs a job that doesn’t require that

I’m OK with staying put, but biggest thing I miss about “digital nomads” is a cheerful and supportive community of laptop workers that support each other in their work and life.

Local coworking spaces are not about community and don’t look that cheerful either. They are more like offices. That’s not an issue with Eindhoven, but the Netherlands per se. It might be even a wider issue in Europe, because I haven’t found anything like what I experienced in Asia’s coworking spaces anywhere else here.

So this is my attempt to bring a cheerful and encouraging coworking vibe to Eindhoven. Now there is a small Telegram group with 24 members as of date. It so happened that the first active members spoke Russian, so the main language of communication is Russian, but everyone can easily switch to English. So if you’re living here or passing by, no matter who you are - feel free to join.

We have explored a lot of places in Eindhoven where one can work with a laptop and have a decent cup of coffee in the process. And here is a list of places that our community approves.

Lucifer Coffee

This place comes with decent coffee, separate laptop tables equipped with power sockets and a great atmosphere. My personal favorite is their “daily soups”, I’m a big fan of soups and they often have really decent ones.

There are two of them in the city:

One next to the central station - this one is the biggest and has a lot of space. By far my favorite spot to work at, there are also a lot of food choices within walking distance.
Another one in the heart of city - a bit dark and you are only allowed to work on one big table. But a decent option nevertheless.

Zwartwit Koffie

https://maps.app.goo.gl/yRdrzL2Mr4ztryHb6

Coffee place that started it all. This is where I met first group members and most of my first friends in town. By far the friendliest place in town – visitors are happy to have a chit-chat, even staff stick around longer to ask how you are doing.

Unfortunately, this place has switched owners and coffee quality varies these days. They switch recipes and beans a lot, sometimes it’s great, sometimes not at all.

Hubble Community Café

https://maps.app.goo.gl/oxkcorPRa6d5GXnb6

This is a university coffee place, but it’s open to the general public. One thing about universities is that they usually have the cheapest food on premises. It doesn’t get any cheaper than here.

Coffee is decent and cheap as well.

Eindhoven Public Library

https://maps.app.goo.gl/1M3Pbj8wUbMMQLhQ9

Eindhoven has a fantastic library, works really late too (until 19:00). So if all the coffee places are closed and you don’t feel like going home - this is a fantastic place.

Usually it’s really quiet here, so it’s a perfect place to take a call. Not the case when there is a school break - it gets overrun by kids.

Seats2meet

https://seats2meet.com

I’ve been bad mouthing coworking places, but this one is the closest to social coworking places I’ve found in Europe. If you pre-register, they will most likely have a free spot for you and free coffee. Even though the coffee is free, quality is pretty decent.

Douwe Egberts Café

https://maps.app.goo.gl/cboG4K6CW98q1dx37

My least favorite coffee place, because I absolutely don’t like their coffee, my wife loves it though. Everyone’s tastes are different, so you might like it. I usually compensate with their smoothies or tea, those are great. Also decent selection of snacks.

But the biggest advantage here is two huge floors with a lot of sitting places. When every other place is full, you can always find a spot here.

If you know of any other spaces that we should check out – let me know. Otherwise will be happy to see you join our small group.

Nothing Phone 2a

Mon, 14 Oct 2024 22:09:00 +0000

Someone stepped on my trusted OnePlus Nord 2T at the gym, and the screen broke in 3 different places. It was my mistake in the first place, so after reflecting on my bad habit of throwing things around the gym, I decided to buy another phone.

I never buy flagship phones and stay within the medium-top range category. It’s not that I can’t afford a more expensive phone; there’s just not much justification for me to have a phone that costs more than 400 EUR.

There’s a new mobile maker underdog in Europe that offers phones in that range - Nothing.tech! So, I bought a Nothing Phone 2a to support a European hardware startup. Building phones in our day and age is not easy, especially for a company in Europe - we should support such underdogs.

It’s been a week since the Nothing Phone arrived at our house.

There are things that threw me off immediately about the phone, but after a week together, I’m coming to terms with those quirks.

It charges slower than my previous phone (80W versus 45W). As I understand, charging speeds over 60W are not great for long-term battery health. After a couple of years, 80W charging started to show on my Nord 2T; it barely lasted a day. The Nothing Phone lasts me a couple of days on a single charge, and I assume with the compromise on charging speed, this nice feature would last longer.
The phone’s back is uncompromisingly plastic without any attempts to hide it. Nothing made it look cool, but the tactile feeling is so unusual that it still feels like a kid’s toy in my hands. But I’m getting used to this feeling!
The official case makes the phone rather bulky and heavy; the phone without it is lighter and thinner. I absolutely regret buying that case. It feels like an afterthought and an extra they make money on.
Most Android phones have a bottom bar with a couple of buttons that allow you to go back or see all active apps. Well, Nothing completely ditched that, replacing it with gestures. This gives more screen estate, but it still takes me a couple of attempts to get those gestures right. If only they had a setting to bring that bar back!

These 4 are my main complaints; everything else is praise.

I love this monochrome theme! The screen seems really good. Everything feels snappy. Their camera placement is actually very convenient; I hardly ever touch it with my fingers by accident. And the phone is running Android 15, while Nord still uses Android 12 (so much for promised updates, huh?).

But the strangest thing is that you can submit feedback, and the company actively answers it. More than that, they suggest how to resolve those complaints. I’m very actively submitting bugs and feedback about hardware and software in use, but Nothing is the only hardware company that actually responds!

I have little experience with flagship phones. I could probably get a better processor or a camera that would cost me 4x as much - but I absolutely don’t need any of that. If I numb my tactile feelings and forget that I’m holding a piece of plastic in my hands, the Nothing Phone 2a does feel premium!

Stanislav (Stas) Katkov

Mutation testing in the age of LLMs

Mutating OSS

webhukhs gem

yard-markdown gem

rdoc-markdown gem

Lessons learned

Signing and notarizing a Mac app on Linux

Developer ID Application (aka .p12)

1. Generate a private key

2. Generate a Certificate Signing Request (CSR)

3. Upload the CSR to Apple’s Developer Portal

Steps to Create the .p12

Getting the .p8 key

Assembling all of this together

GoReleaser

GitHub Actions

Mise

Testing

Closing notes

Let it rip

(yard|rdoc)-markdown gems

Let it rip

Pupil outdid its master

Warning about deprecations in Ruby

ActiveSupport::Deprecation

Kernel.warn

Ordering Estonian ID on Linux!

Getting a smart card reader to work

“The PSCS service, required for using the ID-card, is not working”

“No card readers found”

Integrating the card reader with Firefox

Conclusion

From zsh to fish shell

Why

Nothing fish-y here

Powerline prompt

Directory jumper

fzf/history search

Conclusion

Software License management with Polar.sh

Brief idea

Requirements for licensing solution

Licensing Server

License Activation

Activate

Validate

Deactivate

Identifying a Machine

License File

Final notes

Strange thing about happiness.

Coworking in Eindhoven

Lucifer Coffee

Zwartwit Koffie

Hubble Community Café

Eindhoven Public Library

Seats2meet

Douwe Egberts Café

Nothing Phone 2a

Developer ID Application (aka `.p12`)

Steps to Create the `.p12`

Getting the `.p8` key