Forem: Jonas Brømsø

punycode Release v0.15.0

Jonas Brømsø — Tue, 30 Dec 2025 18:49:58 +0000

I wanted to do some cleaning up my various repositories on GitHub, I did not get very far, before I got caught up looking and an old issue and an old branch.

The issue (#34), was on problems with punycode and certain Unicode characters. I have attempted to wrap my head around this problem on a couple of occasions before, but never really got anywhere. But I had this old branch where I had started to look into it, so I decided to pick it up again.

This is the description from the issue:

Hey, Punycodes/Emojis containing Zero Width Joiner are not handled the right way.

xn--8k8hlfr9n should be 🧑🏾‍🎨 not 🧑🏾🎨

punycode 🧑🏾‍🎨 shows xn--1ug6825plhas9r instead of xn--8k8hlfr9n.

Any chance to fix this?

After some digging into the Unicode Standard, I found that the Zero Width Joiner (ZWJ) is used to create compound characters by joining multiple characters together. In this case, the ZWJ is used to combine the base character (🧑🏾) with the additional character (🎨) to form a single compound character (🧑🏾‍🎨).

I realized that the existing implementation of punycode did not account for the ZWJ when encoding and decoding characters. To fix this, I modified the encoding and decoding functions to handle the ZWJ.

After implementing the changes, I tested the updated punycode implementation with various inputs, including those containing the ZWJ. The tests confirmed that the issue was resolved, and the correct punycode representation was generated for characters with ZWJ.

In the branch I had started looking into exchaging the core library, since after all the client in my repository is just a CLI client using existing implementations.

With the lastest update, it can now output:

./punycode xn--8k8hlfr9n
🧑🏾🎨

and:

./punycode xn--1ug6825plhas9r
🧑🏾‍🎨

I checked the two decodings against online implementations, and they all agree on the same output.

So I believe my code is not doing it right.

But if you re-read the original issue:

xn--8k8hlfr9n should be 🧑🏾‍🎨 not 🧑🏾🎨

punycode 🧑🏾‍🎨 shows xn--1ug6825plhas9r instead of xn--8k8hlfr9n.

So my client might still be doing it wrong, since it decodes xn--8k8hlfr9n to 🧑🏾🎨, while the issue reporter expects it to decode to 🧑🏾‍🎨.

But if I check it against the listed online implementations, my client is now aligned with these.

I have closed the issue as a wont fix, since I believe the issue reporter has the report the wrong way around, but I have requested that if more information is available, they should re-open the issue or open a new one.

The issue originates from 2023 and is part of my path to learning Go and you can also read from the documentation:

This utility was created, when in the process of learning Go. I have worked in the DNS and domain name business for a decade so it was only natural to work on something I know when learning Go.

This particular repository touched the following topics:

Learning to make CLI tools

Making an executable distributable and installable component

Reading data from the CLI

Reading data from STDIN

Testing a CLI tool / Main function in Go

So it might never be perfect, but it has served its purpose well and another solution could be to only handle the part with is relevant to DNS, which initself is only a subset of the full Unicode standard, but a rabbithole of it's own.

Any suggestions or ideas for improvements are welcome, just open an issue or a pull request on the repository.

The repository and tool chain had not been touched in a long time, so I had to make release v0.16.0 to get it working with the latest Go version and modules.

Feature and Maintenance Release 0.56.0 of the GitHub Action for Checking Spelling

Jonas Brømsø — Sat, 27 Dec 2025 16:58:45 +0000

A request was received for support for Portuguese for the GitHub Action for Checking Spelling.

Due to Christmas and work as I was not able to act as fast as with the last release, but today I found some time to make the release.

The release includes:

Support for Portuguese language including the Brazilian variant
Update of the Docker base image

So it is a combined feature and maintenance release and possibly the last of the year.

There is another interesting feature request open, which I hope to get started on, so next year could start with another feature release:

"Summarize results as a markdown table"

Change log for: 0.56.0

0.56.0, 2025-12-27, feature and maintenance release, update not required

Support for Portuguese (Portugal and Brazil) for both Hunspell and Aspell, requested by: @mdiazgoncalves via issue #298
Docker image updated to Python 3.14.2 trixie slim Release notes for Python 3.14.2

Maintenance Release 0.55.0 of the GitHub Action for Checking Spelling

Jonas Brømsø — Fri, 28 Nov 2025 13:10:55 +0000

A quick maintenance release for the GitHub Action for Checking Spelling was made yesterday.

The other day the repository got a new issue which requested enabling of use of large Aspell dictionaries.

The GitHub action however is just a wrapper for PySpelling so I sent the user in that direction, also because this was something I believe was more in the realm of PySpelling than the GitHub Action.

Not long after a new release of PySpelling (2.12.1) was made, so I reopened the issue, since I needed to update the action with the new release to meet the need of the user and the original request and it was easier to keep track of the request this way.

Later the user wrote to me:

Thanks! I’m amazed at how quickly the guy over at PySpelling made the change and release.

Hmmmmm...

I decided to step my game up and luckily I had an window of opportunity, so I made the release numbered 0.55.0 which contains an update of the core component PySpelling from version 2.12.1.

At this time I am not sure how the Aspell setting for large dictionaries is enabled/configured, I have not been able to find any documentation on this, but at least the action is aligned with the core component - I hope this works out for the user.

Change log for: 0.55.0

0.55.0, 2025-11-27, maintenance release, update not required

Via an issue #293 from @shoverbj, an update to the core component PySpelling from version 2.12.0 to version 2.12.1 was made, this allows for use of large dictionaries with Aspell

Maintenance release 2.09 for the Perl Distribution Workflow

Jonas Brømsø — Sun, 23 Nov 2025 09:49:50 +0000

This release follows up on release 2.08 and hopefully stabilizes the test suite even further.

At the same time we are taking a first step towards the next major release by deprecating the use of XML configuration files. The preferred format for configuration files is now YAML. The XML support will be removed in a future major release, for now this is just a deprecation notice and several warnings from the test suite.

When we did the last major release to version 2, see the blog post:

"Major Release 2 of the Perl Distribution Workflow"

We caused some grievances for one of our users, afterwards we discussed that perhaps the distribution should have been renamed to Workflow2 to better reflect the breaking changes and to make a more clear distinction and separation. However, at the time we did not expect this to be a problem since we wanted to keep the distribution name simple and easy to remember. Instead we will try to communicate breaking changes more clearly in future major releases.

But let's see how this pans out as we are slowly approaching the next major release and what we decide on moving forward.

The challenge with Perl and version numbers is complex and now that the mentioned problems got sorted out, I do not believe we would experience them again and I for one want to avoid renaming the distribution in future major releases.

The release is available on CPAN and GitHub:

GitHub perl-workflow release 2.09

Change log for Perl Workflow release 2.09.

2.09 2025-11-23 maintenance release, update not required

Deprecation notice of use of XML configuration files, issue #125 and deprecation notices implementation by @ehuelsmann via PR #256.
- YAML configuration files are now the preferred format for configuration of Workflow instances. The XML implementation was based on XML::Simple, which itself has been discouraged for use for several years. The distribution still supports XML configuration files, but this support will be removed in a future unscheduled major release.
Improvements to test suite, PR #275 by @ehuelsmann. This is a follow up on release 2.08, since we spotted the issue in the tests running as part of the CI pipeline on GitHub

Tooth to Tail

Jonas Brømsø — Fri, 14 Nov 2025 17:31:07 +0000

A development team consist of people with various roles and responsibilities. Over the cause of my career I have had many different roles ranging from developer, to release manager, scrum master, build engineer, occasional tester and finally product manger/owner. I have been called bottleneck and show-stopper and what I have observed is the difficulty of getting a team to be balanced.

At some point I fell over the military term "Tooth to Tail Ratio" and I found it to be interesting in regards to the challenge of balancing a team, so you do not get too many bottlenecks, as for the show-stopper part, I believe it is my personality that sometimes question decisions and that is not always appreciated.

The tooth to tail ratio is a military concept that describes the ratio of combat troops (tooth) to support personnel (tail) in a military force. A higher tooth to tail ratio indicates a larger proportion of combat troops, while a lower ratio indicates a larger proportion of support personnel. The concept is used to evaluate the efficiency and effectiveness of military forces, as well as to inform decisions about resource allocation and force structure.

As a development team we are not exactly in a combat situation or necessarily in a military context, but thinking about team composition and team dynamics can be informed by the tooth to tail ratio concept. Since a balanced team with the right mix of skills and roles can help ensure that the team is able to deliver high-quality software efficiently and effectively.

There are critics of the tooth to tail ratio concept, but this is within the military context, so at this time, we do not need to go into that.

You can read more about tooth to tail ratio on Wikipedia.

The concept of tooth to tail ratio was interesting since it made me reflect on the challenges of balancing a development team. So if you can:

identify the roles and responsibilities of team members
assess the skills and expertise of team members
evaluate the workload and capacity of team members

Then you can start to think about how to balance the team, based on numbers.

Another approach which I do however find more interesting, which came from reflecting on the above, was finding back to the essence of the team concept. If you read the referenced wikipedia article, the following line is interesting:

While both "tooth" and "tail" soldiers may find themselves in combat

Meaning your might have a primary role, but you can be flexible and take on other roles as needed.

And this is very interesting. I have tried to work with teams where we had:

developers
testers
release managers
scrum masters
product owners

We are worked committed to finishing what we had defined as the goal of our sprint, the timebox set to accomplish a certain milestone/goal as a release or a feature set or similar.

Assignments vary and you can estimate, but you should not rely to much estimates it is a planning tool IMHO and things might change. Sometimes things take longer or a colleague needs help and time is not spent where planned or some other external factor impacts execution of the plan.

But in this team, the primary goal was to get the work done, and if that meant that a developer needed to help with testing, then that was what happened.

This sounds formidable, but it is a culture and culture building and changes are hard. If you succeed though, you get a team that is flexible and can adapt to changing circumstances and has a very strong team spirit.

We have a tendency to want to stick to our defined roles, I myself am guilty of this, but oftentimes it is very beneficial and educational to do something else, you gain a lot of insight from getting a different perspective.

In software development, we often talk about getting close to the users, which is great, but what if you could start by understanding your team mates and their roles better.

Tooth to tail is interesting, but perhaps the key is in breaking down the barriers between roles and responsibilities and creating a culture where everyone is committed to the team's success and bringing value to the customers/stakeholders. The roles in modern software development is are requires skills and expertise, to the primary role is of outmost importance, but being flexible and adaptable is a great skill to have as well.

And numbers are interesting, but I guess it would be more valuable to do the numbers game on outcome and value rather than team organization..

So let me end with another military term/slogan:

"Improvise, Adapt, and Overcome"

Perhaps that will work, even in more peaceful settings.

Use Markdownlint for your documentation

Jonas Brømsø — Thu, 13 Nov 2025 06:13:59 +0000

This blog post is a TIL (Today I Learned) about using Markdownlint as part of your documentation workflow on GitHub lifted from my TIL collection.

Markdownlint-CLI is one of those all-round tools, which are always within grasp when you need them.

I lint my markdown on the command line
I lint my markdown my editor of choice VScode
I lint my markdown as a GitHub Action as part of my CI pipeline

So lets go over the GitHub Action part.

When I set up a repository on GitHub, which going to hold a significant amount of Markdown, I add a Markdownlint configuration:

In the root of the repository I add the file: .markdownlint.json

{
    "default": true
}

The moment I have done that, I can use the command line tool and my editor let's me know I entered bad Markdown.

Next step is configuring the action, so I add the following file to the directory: .github/workflows/markdownlint.yml, I do this so all of the warnings and recommendations that Markdownlint I do not catch, gets captured as part of the continuous integration on GitHub.

The file contents looks something along the lines of:

name: Markdownlint Action
on:
  push:
    paths:
      - '**/*.md'
      - '.markdownlintignore'
      - '.markdownlint.json'
  pull_request:
    paths:
      - '**/*.md'
      - '.markdownlintignore'
      - '.markdownlint.json'

permissions: read-all

jobs:
  build:
    name: Markdownlint
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
      - name: Markdownlint
        uses: nosborn/github-action-markdown-cli@508d6cefd8f0cc99eab5d2d4685b1d5f470042c1 # v3.5.0
        continue-on-error: true
        with:
          files: .
          config_file: ".markdownlint.json"

The configuration has a lot of things going on:

I have configured what triggers the linting process
- Markdown files of course, if you name them differently lik: *.mkdn etc. you need to take that into consideration
- But also changes to the tool chain:
- .markdownlint.json specifies our rules, so do we have changes to the rules we need a run
- .markdownlintignore a classical ignore file for Markdownlint, does this file have changes we need a run
The action only needs read permissions
The uses statements pointing to the actions used are pinned, which is a security recommendation
I use continue-on-error as Markdown linting errors are often not critical to the repository
The config_file parameter is for hwen you want to locate your configuration in another place to declutter the root of your repository, I just have it here for convenience, see more below

The action uses nosborn/github-action-markdown-cli can be found on the GitHub marketplace and since it is based on markdownlint-cli I have no challenges with the configuration outlined above since it is the same configuration used for the CLI tool: markdownlint and additionally VScode via the plugin from the VScode marketplace.

As I add more and more Markdown the warnings/recommendations start to appear and I adjust the configuration. For this repository is looks like this at the time of writing.

{
    "default": true,
    "ul-style": { "style": "dash" },
    "html": false,
    "line-length": false,
    "fenced-code-language": false,
    "no-hard-tabs": true,
    "blanks-around-headings": false,
    "ul-indent": false,
    "commands-show-output": false,
    "no-bare-urls": false,
    "ol-prefix": false,
    "no-trailing-punctuation": false,
    "no-space-in-links": false,
    "no-space-in-emphasis": false,
    "emphasis-style": { "style": "underscore" },
    "strong-style": { "style": "asterisk" }
}

For the rules I have configured I would like to emphasize:

"ul-style": { "style": "dash" }
"emphasis-style": { "style": "underscore" }
"strong-style": { "style": "asterisk" }

Since Markdown is very flexible, I prefer to have a very uniform style, so I use:

- (dash) for lists, why? this could also be: + (plus) or * (asterisk)
_ (underscore) for italics/emphasis, why? - two consecutive underscores is also bold
* (asterisk) for bold/strong, why? - a single asterisk is emphasis, two is bold, asterisk surrounded by spaces is a bullet

There might be cases where I have to bend this rules, so I do that on a per repository basis.

Decluttering Your Repository Root Directory

As your toolbox grow and your repository adopt more and more tooling, you might experience that your repository root directory clutters with all sort of repository specific configurations.

Luckily the action can be configured to point to an alternative path for the configuration file.

[!WARNING]
This below is not compatible with the intuitive and out of the box solution of having the .markdownlint.json in the root directory for easy detection by the CLI tool or VScode.

with:
    files: .
    config_file: ".markdownlint.json"

You can move the file into a sub-directory, for example .github/.

with:
    files: .
    config_file: ".github/markdownlint.json"

Avoiding Markdownlint Conflicts

Sometimes you adopt Markdown files from other projects and these might not adhere to your specific Markdown linting rule set and hence they will get reported as items for your attention.

Examples of these files can be:

License descriptions
Code of Conduct Policy

Luckily Markdownlint-CLI supports adding an ignore file as you know it from Git ignore files.

An example for a markdownlintignore file:

LICENCE.md
CODE_OF_CONDUCT.md

Next step is telling the action about the location of the ignore file:

with:
    files: .
    config_file: ".github/markdownlint.json"
    ignore_path: ".github/markdownlintignore"

This does mean that you might have some challenges in regards to the additional tooling, like VScode and the command line tool.

AFAICT the VScode extension does not allow for configuring the path to the ignore file.

[!NOTE]
Do note that the files moved to .github has the dot removed, since there is not need to hide them as such, when the directory is hidden

The CLI tool has the following options: -p/--ignore-path, but these take path arguments and not the path to an ignore file, so some cluttering will occur.

Resources and References

Bug fix release 2.08 for the Perl Distribution Workflow

Jonas Brømsø — Wed, 12 Nov 2025 16:13:43 +0000

We got an issue reported by long term Perl user and PAUSE gatekeeper @ANDK, an issue had been observed and was reported via the smoke testing framework available as CPAN-testers.

ANDK had debugged the issue, which is much appreciated, I was unable to reproduce it locally, but @ehuelsmann was fast to provide a patch that we believe fixes the issue.

GitHub perl-workflow release 2.08

This kind of bugs are tricky, especially if you cannot reproduce them, but the area of the code pointed out by ANDK made sense, and Erik's patch also made sense - it is a fragile area of the code and it might be related to tests, but we want our tests and main code to be as robust as possible, so we can trust it.

I am not sure this is a real heisenbug, but it does feel like it.

Change log from the lastest release:

2.08 2025-11-12 bug fix release, update not required

Fixed

Issue: #271 reported by @andk. Fixed via PR: #272 by @ehuelsmann This issue was discovered by the CPAN smoke testers, the report can be found on CPAN Testers

Bug fix release 2.07 for the Perl Distribution Workflow

Jonas Brømsø — Sat, 08 Nov 2025 10:35:26 +0000

My fellow contributor @ehuelsmann located a regression since we spun off 2.X from 1.X.

GitHub perl-workflow release 2.07

The regression was observed by @ehuelsmann and he provided a PR with a fix.

The regression was a change to return values and one of the interesting Perl discussions on whether to return undef or just do return. Anyway the fix reinstates the previous behavior and returns undef.

Here follows the change log for the bug fix release.

2.07 2025-11-08 bug fix release, update not required

Fixed

Issue: #266 discovered by Erik Huelsmann. A regression introduced with 2.X releases. Fixed via PR: #267 also by Erik Huelsmann

Feature Release 0.54.0 of the GitHub Action for Checking Spelling

Jonas Brømsø — Wed, 05 Nov 2025 21:01:41 +0000

A feature release for the GitHub Action for Checking Spelling has just been made.

The release is numbered 0.54.0 and contains an update of the core component PySpelling from version 2.11 to 2.12. The update allows for the configuration parameters jobs to be set to: 0 to allow for use of maximum number of cores.

See the documentation for PySpelling and of course 0.54.0 of this action.

The support for this setting was introduced with release 2.10 of PySpelling, which was adopted in release 0.36.0 of this action.

Happy spellchecking on even more cores for all your spellcheck needs!

Maintenance Releases 0.53.0 of the GitHub Action for Checking Spelling

Jonas Brømsø — Sun, 26 Oct 2025 13:07:24 +0000

Another maintenance release for the GitHub Action for Checking Spelling has seen the light of day yesterday.

The release is numbered 0.53.0 and contains the following changes.

Update of Docker Python base image to python:3.14.0-trixie-slim.

This is both an update to Python version and OS version. So we have not moved from Debian Bookworm to Trixie and from Python 3.13.7 to Python 3.14.0.

The Release notes for Python 3.14.0 are available.

The update originated in a PR from Dependabot #274, the challenges with these PRs is that they only mention the checksums in short form and not the full details of the base image update, so getting the details requires some research.

I outlined some of the challenges in an earlier blog post and it used AI tooling to analyse DockerHub data to understand what was being offered via the PR.

The case was the same for this PR, but this time I was better prepared and new what questions to ask, so after some prompting I got the details I needed with

Python version
Docker image
OS version

And with some iterations on the builds I got a working Docker image for the action and I got it tested locally, before releasing and shipping.

Since wasting AI credits is wasteful and the process somewhat repeatable, I asked the AI to generate a shell script that could be used to fetch the details from DockerHub, so I could use it next time a similar PR would show up, processing it would become significantly easier, faster and cheaper using a script doing the steps an AI would do and I would avoid the prompting.

Baseline - ported to Go

Jonas Brømsø — Tue, 07 Oct 2025 17:31:20 +0000

I got an idea for an application that would help me analysis the a large code base across multiple repositories using all your favorite text tools, my own being:

ag
find
xargs
perl
and so forth

I blogged about the idea in Baseline a parallel Git Universe/Concept for Easy Searching and started working on a prototype.

The first working version was a basic shell script, that utilized Git commands and it worked well enough for a first version.

It did however lack features like:

repository discovery
private repository support
better UI/UX

Now I finally got some time to give it some more attention and recently I ported the shell script to Go.

Last version of the shell script was tagged as v0.2.0 and I am now at a working Go version tagged as v0.5.0.

With version 0.5.0:

The UI/UX has been improved
Repository discovery has been added, currently supporting:
- GitHub (public and private)
- BitBucket (public and private)

For now I have only scratched my own itch, so there might be variations to the above mentioned use cases the application do not support, so please consider this vary much pre-release software and do note that features might change in future releases and all use is at your own risk, but read the code, even though it is AI generated, it is still easy to read and understand.

There is still a lot of work to do, many features to add and evaluating and testing the concept more. And about that the implementation has been implemented primarily using a coding agent.

This speeds up the process and since I actually just needed this for some other work, it did not want for this to take up too much time.

Next step for me is to add more features, but I want to use it some more for some real work, then I can decide on what to prioritize next.

Right now I am pondering about:

Adding a configuration file
UI/UX improvements

Since I do not think the UI/UX is quite there yet and I want to make it easier to understand what is going on,

The addition of a configuration file would also make it easier to customize the behavior of the tool and would eliminate the high number of command line options.

I will keep you posted on the progress, if you have suggestions or feedback, please let me know.

You can find the project at: GitHub: jonasbn/baseline.

WIP is waste

Jonas Brømsø — Fri, 19 Sep 2025 19:01:03 +0000

I have been referring to this article: "WIP is waste" from Thoughtbot by Jared Turner on multiple occasions and sharing it with my colleages. I know it is an opinion piece, but it echoes my own experience and perspective on work, projects, and tasks.

The article is short, but it carries some good material. The essence is to get tasks out of WIP (Work In Progress) as fast as possible, because the longer something is in WIP and just having something in WIP is wasted value and postponed outcome and opportunity.

The article outlines these examples:

It’s done, I’m just waiting on a review
It’s complete, I just need to do some final testing
It’s ready, I just need to merge and deploy

And the conclusions:

Before a task is shipped it provides zero value.
Any work in progress is pure cost.
Two tasks in progress adds cost, for no value.
Only after shipping do you create value. Always ship.
One task shipped is infinitely better than 4 tasks “almost done”.
Ship something of value first. Then begin something new.

My own experience and observations are variations of the examples above, so here are some additional examples:

In a setup with multiple roles, hand over between roles causes delays
Running too many things in parallel/multitasking causes delays
Lack of focus causes delays
Code in branches not merged is not value
Pull Requests not reviewed and merged is not value
Work not deployed is not value

This is not to say that everything must be rushed through, but rather that the focus should be on getting things done and out of WIP as fast as possible. This also means that if something is not moving forward, it should be evaluated if it is worth continuing or if it should be terminated.

Another good argument for getting things done, is that the work in the future, will be based is based on what be delivered now. Both the learnings and the actual deliverables. So the sooner something is delivered, the sooner it can be used as a foundation for further work.

You need a balance between start and closing of tasks. If you start too many things, you will have too many things in WIP and not enough things done. If you close too many things, you will not have enough things in WIP to work on. You need to find a balance that works for you and your team.

I have experienced a team, keeping starting too many bug fixes meaning that the bug fixes got delayed getting finished and deployed. A proper triage and prioritization of bug fixes, would have helped. Focusing on getting a few bug fixes done and deployed, would have been better than having many bug fixes in progress and fewer deployed and at some point the same bugs are being reported again and you end up in a bug administration soup.

Another lack of focus example, was a collague keeping starting new initiatives and features, but when as they got developed and tested, they ended up not being deployed for several sprints awaiting UAT. It seemed as if the focus was on starting new things, but as it was started it was no longer interesting. Compared to other examples of WIP, this was very expensive, since the work was done.

So my conclusions are:

Focus on getting things done and out of WIP as fast as possible, keyword is focus
If something is not moving forward, evaluate if it is worth continuing or if it should be terminated
Prioritize and triage tasks to avoid too many things in WIP
Focus on getting a few things progressing, completed and deployed, rather than many things in slow progress
Find a balance between starting and closing tasks
Use what is delivered as a foundation for further work