Antoine Bolvy

HiDPI Electron <37 apps on Sway

Sat, 22 Nov 2025 17:55:00 +0000

Electron 38 ships with Chromium 140 which landed this change which made the Ozone (Chromium’s platform abstraction layer) feature detection “auto” by default (from, like not feature detecting at all, apparently). It bases it’s decision on the XDG_SESSION_TYPE environment variable.

Previously I always had to add those flags to the command line:

/usr/bin/obsidian --enable-features=UseOzonePlatform --ozone-platform=wayland

That works but is annoying: you either need a terminal open and remind yourself to not use Albert (the launcher I’m using).

I also tried patching the installed .desktop files:

# copy and patch a desktop entry (one-off)
desktop-file-install --dir=$HOME/.local/share/applications /usr/share/applications/obsidian.desktop
# then edit ~/.local/share/applications/obsidian.desktop and add the flags to Exec=

It worked, but I was looking for a more permanent solution.

This answer on the Unix Stack Exchange hinted me to use the ELECTRON_OZONE_PLATFORM_HINT environment variable, which is supported by electron between version 28 and 38 (at which point it was removed, because unnecessary).

I initially tried to edit my ~/.profile:

export ELECTRON_OZONE_PLATFORM_HINT=wayland

However, this wasn’t working:

Albert was still launching apps with low DPI.
Launching the app from the terminal (without flags) finally used HiDPI, but I was back to square one.

What worked was embracing systemd (that I don’t know enough about) and discovering a new way of setting environment variables:

cat ~/.config/environment.d/electron-hidpi.conf
ELECTRON_OZONE_PLATFORM_HINT=wayland

Another reboot later and Albert was finally launching apps with HiDPI.

That will do, until all my apps are not using Electron 38 ;)

Do not store your translations in Git

Wed, 19 Nov 2025 22:43:42 +0000

For years, we committed our source translation files to Git. It seemed like the right thing to do—after all, they’re part of the codebase, right?

Turns out, we were making our lives unnecessarily complicated.

I probably Googled too many times how to make gettext faster (Speed up the compilation of Elixir projects that use Gettext, How to speed up your Elixir compile times).

If you’ve been there, keep reading.

(Almost) everything in Git

Our Elixir app uses Gettext, which is pretty much the standard for internationalization. We use Localazy as our translation management platform where our staff translates strings into various languages.

When I joined, we had around 6,000 strings. Now we’re past 10,000. These translations live in PO files (PO stands for Portable Object, don’t ask), and there’s a POT file (T for Template) that drives our Localazy tool to check for new strings.

The first part of the workflow went something like this:

Developer adds a gettext("some new string") call in the code
Developer runs mix gettext.extract to sync the POT file with the codebase, they’d normally also update the PO file manually, but since we consider the code to be the source of truth, we actually wrote a small bit of code to generate the source language PO from the POT.
Developer commits both the code changes AND the PO/POT files

Fortunately, we had already moved away from the automated PR downloading the translations and committing them, but we still had generated files committed. “It makes reviewing spelling mistakes easier” was something we told ourselves to make us feel better.

The Problem: Compile-Time Complexity

Here’s where things got interesting. Since PO files are parsed and gettext calls are inlined at compile time, each locale adds to compile time. We’re talking O(n) complexity where n is the number of locales.

To keep everything “consistent”, we had this de facto standard: always sync the POT file with the list of gettext calls in the code (the source of truth), then commit both the PO (for the source language) and the POT file.

This meant that for each commit (if you added even a single new gettext call), you theoretically needed to run mix gettext.extract. This command recompiles the entire project to evaluate every gettext call and come up with the new strings in both PO and POT files.

1.5 minutes on a beefy laptop it took. Yep, big monolith.

The workflow went something like this:

Once your PR is pushed, CI checks that everything is in sync with mix gettext.extract --check-up-to-date
Once the CI check passes and merged to develop, a daily build sends new strings to Localazy
On deployment, we’d call localazy download to get all translations

As stated, each PR was blocked by a mix gettext.extract --check-up-to-date task, as suggested in the official docs, to check that the files were in sync with the code.

Sounds reasonable, right? Well…

Why we stuck with this workflow for so long

This led to a bunch of different workflows, none of them great:

Some folks would remind themselves to run the extract task before every commit. Takes a minute and a half, breaks your flow, but hey, at least CI won’t fail.
Others were adding all their changes, then tacking on a single commit at the end called gettext. Then maybe do a few fixes. Have a failed build. Add another gettext commit. Not ideal!

For fun here’s an excerpt I got by running git log --grep="gettext"

49bf8947c0 Fixing post rebasing gettext
1184593889 extracting gettext after rebasing
bed14725d1 re-extract gettext following merge
da3a902c6f gettext rebase inconsistancies fix
fb35ff7db6 gettext
59ba9cea53 Update gettext
9bfc4f0fa7 Update gettext
5157e9f85b Update gettext
d04b956baa Update gettext
da096be3c6 Update gettext
fb9963e867 Update gettext
db0b180dc2 use gettext
458706dc87 Update gettext
4d56537088 chore: update gettext files
7f5c25d2a4 chore: format files and update gettext files
7da1412226 chore: update gettext files
a745b2f3a7 chore: update gettext files (again)
9fe8e478c9 chore: update gettext files
b93e30f897 chore: update gettext files
78ffae2e81 chore: update gettext files
c461756cf0 chore: update gettext files
3f3ca6df16 chore: update gettext files
387cbb2000 chore: update gettext files
69d8629e3e gettext
5960bb2b85 Fixed gettext error.
7944862c4c Update gettext
fcdf619670 Update gettext
4c46452dc8 Update gettext
0c89da460d Update gettext
bfc62e2664 Update gettext
6460b6f64d Use gettext
41c35c816d chore: update gettext files
42bc1eeccd update gettext
375591249d update gettext
34f7d00422 Update gettext stuff after rebase ...
aef7a8ed0e chore: update gettext files
f64b809baa mix gettext
bddd91148a chore: gettext
de0d27b8da mix gettext
516acaa05c chore: gettext and credo
1da19cf8bc mix gettext
4ec345fcd4 chore: update gettext files
849877911e Add gettext
5562a1a5fd Use of gettext_with_link
8697c57525 🌐 gettext
01e72f8aff 🌐 correct gettext for failure document creation
36d676dcce 🌐 updated gettext
df7e8ab5b8 mix gettext
bc80302380 mix gettext
2c5e6108e5 mix gettext
fca475f4df chore: update gettext files
27729fcb4a add virtual field + mix gettext
5cb03227a2 🌐 gettext
31be0b5769 chore: update gettext files
b679fd56fb chore(gettext): 💬 Update gettext keys
d01b0d1cea refactor: 💬 Add missing gettext
205127c537 chore: gettext
d290e1c44d gettext
42e00ddfec 🌐 added more missing gettexts
e8868cda16 🌐 added missing gettext
465f523b09 update gettext
d2442a819e chore: cleanup test gettext
c229b81d35 mix gettext
da5e36e8af mix gettext
af748b8c43 update gettext
534a7b14be mix gettext
9cf4b1fc9e chore: update gettext files
f3b8fa04d1 chore: update gettext files
70df45213c chore: update gettext files
a24d10398b chore: update gettext files
c4a0de5726 update gettext
68b0bda86c 🌐 gettext
edb112487c chore: update gettext files

…Yeah. To try to combat this, we had a very specialized Git pre-commit hook (I wrote it) that did the check automatically, so you wouldn’t discover you forgot to run it in CI. I don’t know if many enabled it!

While a fun exercise, and a gentle reminder that bash is not a real programming language (albeit being the most portable choice, except, well, macOS) and that 400 lines of bash, even if unit tested, will break in any possible way. I believe I must have spent like a full week on that task. All to try having better commits. Duh.

One day, while reviewing yet another gettext commit, it finally clicked.

The Eureka Moment

We don’t have to live like this.

We already have the source of truth: the source code itself. The gettext calls in our Elixir files are what matters. Everything else is derived. Our translations don’t live in the repo anyway, they’re downloaded from Localazy.

We could just extract the POT file when needed, when building in CI to upload to Localazy. And we pull all the PO files anyway when building for production. Sounds obvious now that I write about it.

Two sources of truth. Multiple CI steps. Complex workflows. Pre-commit hooks. Slow extract commands blocking every commit. Conflicts! Do I continue?

The Solution: Extract On Demand

That’s it. No more up-to-date checks blocking every commit. Just extract when needed, in a CI environment, not slowing you down. Upload when appropriate, and download translations as part of your deployment process.

The diff said it all, with all the POT/POs deleted + 100s of lines of tooling:

+49 lines added, -58,939 lines removed

Conclusion

We won’t reclaim the hours of lost build time, but at least that’s some CPU cycles saved for everybody.

Also, if you find yourself writing bash scripts to enforce a workflow, maybe step back and ask: is there a simpler way?

Cleaning up local branches after squash merges

Wed, 01 Oct 2025 12:12:42 +0000

For years, I’ve been using this handy one-liner to clean up merged branches:

git branch --merged | grep -Ev "(^\*|^\+|production|develop|master)" | xargs git branch -d

It worked great: fetch the latest changes, run this command, and all the branches that had been merged would get deleted locally. Clean and simple.

The Problem: Squash Merges Break Everything

Then we enabled squash merges on our team’s repositories. Suddenly, my cleanup command stopped working. Because with squash merges, Git doesn’t consider the original branch as “merged” in the traditional sense:

When you do a regular merge, Git creates a merge commit that has two parents - one from your branch and one from the target branch. The git branch --merged command can trace this history and knows your branch was incorporated.

With squash merges, Git takes all your commits, squashes them into a single new commit, and applies that to the target branch. Your original branch history is essentially discarded. From Git’s perspective, your branch was never “merged” - the content was just copied over in a new commit and it has now way of knowing that it was ever merged.

git branch --merged then returns nothing, and you’re left manually deleting branches or letting them pile up indefinitely. Although I’m keen on letting refactors get out of hand, stashes piling up, and working directory full of uncommitted utility files and tools, branches are the next (PRs are usually up there) best thing to track ongoing work. Having too much around makes the output of git branch pretty much useless and then you have to resort to sorting branches by date or some other criteria.

A Better Solution

After getting frustrated with this a few too many times, I asked around my colleagues they just… don’t care. Okay then. Let’s turn to the internet: quick in our search we discover this Stack Overflow post:

How can I delete all git branches which have been “Squash and Merge” via GitHub?

A oneliner that had some drawbacks stands out on the most upvoted answer:

git checkout -q master && git for-each-ref refs/heads/ "--format=%(refname:short)" | while read branch; do mergeBase=$(git merge-base master $branch) && [[ $(git cherry master $(git commit-tree $(git rev-parse "$branch^{tree}") -p $mergeBase -m _)) == "-"* ]] && git branch -D $branch; done

The core idea is sound ; it creates a synthetic commit that represents what your branch would look like if it were squash-merged, then uses git cherry to see if that commit already exists in the target branch. But it’s not immediately obvious what’s happening or why. It’s hard to understand: If it breaks or behaves unexpectedly, you’re in for a world of hurt.

If it worked 100% of the time, this article wouldn’t exist. I don’t remember the exact details but it wasn’t enough. Also the lack of safety checks, and silent failures made it hard to debug.

So I took ideas from there and there, and wrote a script (with the help of Gemini 2.5, at the time) that could help automating the process further and be more resilient to errors than the above oneliner.

Step 1: Find Remote Branches That Were Deleted

The script uses git remote prune --dry-run to see which remote tracking branches would be pruned:

deleted_on_remote=$(git remote prune $REMOTE_NAME --dry-run 2>&1 | grep '\[would prune\]' | awk '{print $NF}' | sed "s#^$REMOTE_NAME/##")

This gives us a list of branch names that exist locally but have been deleted on the remote. The nice thing is that this is repeatable. The --dry-run flag makes the prune operation a noop so the script is repeatable.

Step 2: Verify Before Deleting

A remote branch deleted doesn’t mean we should automatically delete the local version. What if there are local changes that weren’t pushed?

For each branch marked for deletion, it:

Switches to the branch
Tries to merge it with develop
If the merge results in no changes (meaning the branch content was already squash-merged), it’s safe to delete
If there are differences, it skips deletion and warns you

git switch "$branch"
git merge develop --no-edit --quiet || {
    echo "Merge failed for $branch, skipping deletion."
    continue
}

if ! git diff --quiet develop; then
    echo "Branch $branch has differences with develop, skipping deletion."
    continue
fi

Safety Features

The script includes several safety features:

Autostash: Automatically stashes any uncommitted changes before starting, and pops them when done (or when something goes haywire)
Current branch protection: Never deletes the branch you’re currently on
Confirmation prompt: Shows you exactly which branches will be deleted and asks for confirmation

The Complete Script

Here’s the full script that you can drop into your project:

#!/bin/bash

# --- Configuration ---
REMOTE_NAME="origin" # Change if your remote has a different name

# --- Colors ---
RED='\033[0;31m'
YELLOW='\033[1;33m' # For warnings or info
NC='\033[0m' # No Color

# --- Autostash Setup ---
stash_created=false
# Function to pop the stash if it was created by this script
pop_stash() {
  if [ "$stash_created" = true ]; then
    echo "-----------------------------"
    echo -e "${YELLOW}Popping autostash...${NC}"
    git stash pop || echo -e "${RED}Warning: 'git stash pop' failed. You may need to resolve conflicts manually.${NC}"
  fi
}
# Set a trap to ensure pop_stash is called on any script exit (normal, error, or user abort)
trap pop_stash EXIT

# --- Safety Check: Ensure we are in a git repository ---
if ! git rev-parse --is-inside-work-tree > /dev/null 2>&1; then
  echo -e "${RED}Error: Not inside a Git repository.${NC}"
  exit 1
fi

# --- Autostash Execution ---
# Check for uncommitted changes (staged or unstaged)
if ! git diff-index --quiet HEAD --; then
  echo -e "${YELLOW}Uncommitted changes detected. Creating an autostash...${NC}"
  git stash push -m "autostash-by-cleanup-script-$(date +%s)"
  stash_created=true
  echo "-----------------------------"
fi

echo "Checking for local branches whose remote tracking branches on '$REMOTE_NAME' have been deleted..."

# --- Step 1: Get list of remote branches deleted on the specified remote ---
# Use 'git remote prune --dry-run' which is designed for this.
# Output is like: * [would prune] origin/branch-name
# We extract the part after 'origin/'
deleted_on_remote_raw=$(git remote prune $REMOTE_NAME --dry-run 2>&1)
if [[ $? -ne 0 ]]; then
    echo -e "${RED}Error checking remote prune status. Output:${NC}"
    echo "$deleted_on_remote_raw"
    exit 1
fi

deleted_on_remote=$(echo "$deleted_on_remote_raw" | grep '\[would prune\]' | awk '{print $NF}' | sed "s#^$REMOTE_NAME/##")

if [[ -z "$deleted_on_remote" ]]; then
  echo "No remote branches seem to have been deleted on '$REMOTE_NAME' since last fetch/prune."
  # Optional: Still run fetch -p to actually prune remote refs if needed
  # echo "Running 'git fetch -p' to update remote refs..."
  # git fetch -p $REMOTE_NAME
  exit 0
fi

# --- Step 2: Get list of local branches ---
# Use plumbing 'git for-each-ref' for robustness
local_branches=$(git for-each-ref --format='%(refname:short)' refs/heads/)

# --- Step 3: Get the current branch ---
# Use plumbing 'git symbolic-ref'
current_branch=$(git symbolic-ref --short HEAD 2>/dev/null) || current_branch=""

# --- Step 4: Compare and identify local branches to potentially delete ---
declare -a branches_to_delete # Array to hold branches marked for deletion
declare -a branches_to_display # Array to hold display lines

echo "Comparing with local branches:"
echo "-----------------------------"

has_branches_to_delete=false

while IFS= read -r local_branch; do
  # Ignore the current branch - never delete it automatically
  if [[ "$local_branch" == "$current_branch" ]]; then
    branches_to_display+=("* ${local_branch} (current branch)")
    continue
  fi

  # Check if this local branch exists in the list of deleted remote branches
  # Use grep -Fxq for exact, fixed string, quiet match within the list
  if grep -Fxq "$local_branch" <<< "$deleted_on_remote"; then
    # Found a match - mark for deletion
    branches_to_display+=("- ${RED}${local_branch} (remote deleted)${NC}")
    branches_to_delete+=("$local_branch")
    has_branches_to_delete=true
  else
    # No match - just display normally
    branches_to_display+=("  ${local_branch}")
  fi
done <<< "$local_branches"

# --- Step 5: Display the list ---
if [ ${#branches_to_display[@]} -eq 0 ]; then
    echo "No local branches found."
    exit 0
fi

# Print the collected display lines
for line in "${branches_to_display[@]}"; do
  echo -e "$line"
done
echo "-----------------------------"


# --- Step 6: Check if any branches are marked for deletion ---
if ! $has_branches_to_delete; then
  echo "No local branches correspond to deleted remote branches."
  # Optional: Run fetch -p here if you want to ensure pruning happens even if no local match
  # echo "Running 'git fetch -p' to update remote refs..."
  # git fetch -p $REMOTE_NAME
  exit 0
fi

echo # Newline for clarity before prompt

# --- Step 7: Ask for confirmation ---
# Use '-ei "y"' in read for bash >= 4 (default to 'y')
# Fallback for older bash
read -p "$(echo -e Are you sure you want to delete the ${RED}RED${NC} local branches listed above? \(y/N\):) " response
response_lower=$(echo "$response" | tr '[:upper:]' '[:lower:]') # portable lowercase

# --- Step 8: Perform deletion if confirmed ---
if [[ "$response_lower" == "y" ]]; then
  echo "Proceeding with deletion..."
  deleted_count=0
  error_count=0
  # Actually prune the remote tracking refs first
  # echo "Running 'git fetch -p $REMOTE_NAME' to sync remote refs..."
  # git fetch -p $REMOTE_NAME

  echo "Deleting local branches..."
  for branch in "${branches_to_delete[@]}"; do
    echo -n "Deleting local branch '$branch'... "
    # Use 'git branch -d' (porcelain, but standard and safer as it checks for merged status)
    # Use 'git branch -D' for force deletion if desired.

    git switch "$branch"
    git merge develop --no-edit --quiet || {
      echo -e "${RED}Merge failed for $branch, skipping deletion.${NC}"
      git merge --abort
      ((error_count++))
      continue
    }
    # check if we have some difference with develop
    if ! git diff --quiet develop; then
      # assert slate is pristine before --hard reset
      if ! git diff --quiet; then
        echo -e "${RED}Local changes detected in $branch, aborting merge.${NC}"
        continue
      fi
      git reset --hard HEAD~1
      echo -e "${YELLOW}Branch $branch has differences with develop, skipping deletion.${NC}"
      ((error_count++))
      continue
    fi

    git switch develop

    if git branch -D "$branch"; then
      echo -e "${YELLOW}Deleted.${NC}"
      ((deleted_count++))
    else
      echo -e "${RED}Failed for $branch.${NC}"
      ((error_count++))
    fi
  done
  echo "-----------------------------"
  echo "Deletion complete. $deleted_count branches deleted."
  if [[ $error_count -gt 0 ]]; then
      echo -e "${RED}$error_count branches failed to delete (see messages above).${NC}"
      exit 1 # Exit with error status if deletions failed
  fi
else
  echo "Aborted by user. No local branches were deleted."
  echo "You might still want to run 'git fetch -p $REMOTE_NAME' to prune remote-tracking references."
fi

exit 0

Fixing Flaky Elixir Tests with Randomized Query Ordering

Sat, 30 Aug 2025 12:12:42 +0000

Flaky tests are the bane of a developer’s existence - they pass locally but fail in CI, or worse, pass 9 times out of 10 only to mysteriously fail when you least expect it. A failing CI build leads to fatigue and frustration for everyone involved, so any flaky test should be analyzed and fixed.

We quickly understood that a good part of those flaky tests had the same root cause: database queries without explicit ordering.

The Problem: Unstable Sorting in Database Queries

When we write a query like this:

Repo.all(from u in User)

SQL makes no such guarantee unless you explicitly specify an ORDER BY clause. However, since PostgreSQL often returns results in the same order due to how data is stored and accessed, this lead to subtle bugs in tests: we might write assertions that expect specific ordering, and they’ll pass most of the time by coincidence.

But occasionally, when database statistics change or PostgreSQL chooses a different query plan, the order will change and our tests will fail. These are the dreaded flaky tests. Surprisingly, it happens more often in the CI than locally, leading to hard to reproduce failures.

A proposed solution: Enforcing Randomness

I came up with a solution that’s both simple and effective: what if we could make the ordering explicitly random during tests? This would turn intermittent failures into consistent ones, forcing us to fix the underlying issues.

Here’s the trick - we can override Ecto’s prepare_query/3 callback to add a ORDER BY RANDOM() to any query that doesn’t already have an ordering specified:

defmodule WebApp.Repo do
  @doc """
  Testing helper that enforces sorts in tests/queries. It helps tracking flaky tests and will make them more obvious as the order won't
  be stable unless an order_by clause is specified.
  """
  if Mix.env() == :test do
    @impl true
    def prepare_query(operation, query, opts) when operation == :all do
      query =
        if query.order_bys == [] and is_nil(query.distinct) and query.combinations == [] do
          import Ecto.Query
          order_by(query, fragment("RANDOM()"))
        else
          query
        end

      {query, opts}
    end

    def prepare_query(_operation, query, opts) do
      {query, opts}
    end
  end
end

This implementation uses the prepare_query/3 callback from Ecto.Repo, which allows us to transform queries before they’re executed. When it detects a query without ordering, it adds ORDER BY RANDOM() (excluding some specific queries such as DISTINCT which don’t support/require ordering, naturally).

The beauty of this approach is that it only affects your test environment and even prevents new flaky tests from being introduced - they’ll fail immediately during development rather than randomly in CI months later.

Finding All the Flaky Tests

With our new randomized ordering in place, we’ll quickly discover tests that were silently depending on implicit ordering. But there’s a catch - since the ordering is random, we need to run our test suite multiple times to catch all the issues.

Since I knew about the mix test --failed command, which runs tests that just failed, I knew there was some kind of manifest somewhere that would store the failing tests on disk. After some digging, I discovered it was in the _build directory, more specifically in the _build/test/lib/webapp/.mix/.mix_test_failures file.

So let’s write a script to capture these failures and store them in a more stable file:

defmodule AddStableFailures do
  # The initial failed manifest
  @failed_manifest "_build/test/lib/webapp/.mix/.mix_test_failures"
  # The file to store persistent failures
  @stable_manifest "stable_failures"

  def run do
    if not File.exists?(@failed_manifest) do
      IO.puts("Failed manifest file not found: #{@failed_manifest}")
      System.stop()
    end

    failed_tests =
      @failed_manifest
      |> File.read!()
      |> :erlang.binary_to_term()
      |> elem(1)
      |> Enum.group_by(fn {_, file} -> file end, fn {{_mod, name}, _file} -> name end)

    existing_stable_failures = read_stable_failures()

    new_stable_failures =
      Enum.reduce(failed_tests, existing_stable_failures, fn {file, tests}, acc ->
        Enum.reduce(tests, acc, fn test_name, acc ->
          entry = {file, test_name}

          if Enum.member?(acc, entry) do
            IO.puts("Test already in stable manifest: #{test_name} from #{file}")
            acc
          else
            IO.puts("Adding stable failure: #{test_name} from #{file}")
            [entry | acc]
          end
        end)
      end)

    # Write the entire list back to the file as a single term.
    write_stable_failures(new_stable_failures)
  end

  defp write_stable_failures(terms) do
    File.write!(@stable_manifest, :erlang.term_to_binary(terms))
  end

  defp read_stable_failures do
    case File.read(@stable_manifest) do
      {:ok, binary} -> :erlang.binary_to_term(binary)
      {:error, :enoent} -> []
    end
  end
end

AddStableFailures.run()

Here’s how to use it:

Run your test suite: mix test, some but not all flaky tests will fail.
Run this script to capture failures: elixir accumulate_failures.exs
Repeat steps 1-2 several times to build up a complete list

After a few iterations, you’ll have a pretty comprehensive list of all the tests affected by ordering issues.

Fixing the Tests

Once you’ve identified the flaky tests, fixing them is usually straightforward:

Add explicit ordering to your queries:

# Before
users = Repo.all(from u in User)

# After
users = Repo.all(from u in User, order_by: u.id)

Sort results in memory if the order doesn’t matter for the database:

# Before
assert [user1, user2, user3] = Repo.all(User)

# After
assert Enum.sort_by([user1, user2, user3], & &1.id) == Enum.sort_by(Repo.all(User), & &1.id)

Remove order dependence from the test if possible:

# Before
assert [%{name: "Alice"}, %{name: "Bob"}] = result

# After
assert Enum.count(result) == 2
assert Enum.any?(result, &(&1.name == "Alice"))
assert Enum.any?(result, &(&1.name == "Bob"))

The Results

After implementing this approach at work, we quickly identified and fixed a dozen of flaky tests, most having never been seen before. Our CI became more reliable which is always a good thing.

What’s more, this approach catches potential flaky tests during development. When a developer writes a new test that implicitly depends on ordering, it fails immediately (well, it’s still random so it might take a few runs) on their machine rather than randomly in CI weeks later.

As an added bonus, we’ve made our codebase more robust by adding explicit ordering at places we had forgotten about.

Conclusion

Flaky tests cause a lot of frustration, but they are surprisingly easy to fix once you know what to look for. A good first thing is to ask your team to start tracking failing builds so you can start accumulating data on the frequency and nature of these issues. This will help you prioritize fixes and ensure that your CI pipeline remains stable over time.

Local Elixir development with ASDF

Mon, 20 May 2024 12:12:42 +0000

Some notes I took while submitting my first PR to the Elixir repo.

Local development of Elixir with ASDF

First clone (following the README):

git clone https://github.com/elixir-lang/elixir
cd elixir
make

Takes a minute to compile, then binaries sit in bin/. I like it a lot that the whole build process is only a make away, refreshing!

Configuring `asdf`

Now we want to use that version in our project. Our project uses ASDF to manage our tools, so we need to tell ASDF about the local version.

Edit .tools-version like so:

diff --git a/.tool-versions b/.tool-versions
index 0a011338b4..d5ecff1f5a 100644
--- a/.tool-versions
+++ b/.tool-versions
@@ -1,3 +1,3 @@
-elixir 1.15.6-otp-26
+elixir path:../elixir
 erlang 26.1

Here I cloned the Elixir repo in the parent directory of my project, so I can use a relative path. You can use an absolute path too.

Testing

In your repo, run iex, and you should see the version you just compiled:

~/git/elixir-dev elixir-dev*
❯ iex
Erlang/OTP 26 [erts-14.1] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [jit:ns]

Interactive Elixir (1.17.0-dev) - press Ctrl+C to exit (type h() ENTER for help)
                           ^^^
                             |
                             +-- here!

Streamlining `git commit --fixup` and `git rebase --autosquash` with `gfrauto`

Wed, 01 May 2024 12:12:42 +0000

One of the things I like about Git is the ability to fixup commits. It’s a great way to keep the history clean and make sure that changes are grouped together, in logical, atomic commits.

This makes reviewing easier, and I want to provide tooling to other folks that might not know about this feature at all – or might not be using it as much as they could because it’s a bit cumbersome.

Intro

The problem with git commit --fixup is that it requires you to provide the commit hash of the commit you want to fixup. The usual workflow is to blame the line you want to fix (which is a pain, because you’ll have a ton of Not Committed Yet lines), copy the hash, and then run git commit --fixup <hash>.

Helpful tip though, you can get rid of the Not Committed Yet lines by adding HEAD to the blame command. For example, git blame HEAD -- <file>, but that’s not something that the Sublime Text plugin I use does.

Then, when you’re ready to squash the fixup commit, you need to run git rebase -i --autosquash main, it opens the editor, then save and quit.

Hopefully, you correctly identified the commit you wanted to fixup, and you’re done.

Now, imagine we get a PR review, and we have 10s of changes to make. That’s a lot of manual work.

Automated fixup with `gfra`

Now the function I’ll introduce doesn’t solve the problem of identifying the commit you want to fixup, but it does automate the process of creating the fixup commit and rebasing interactively to autosquash the changes.

gfra() {
    git commit --fixup="$1" --no-verify; git rebase --autosquash "$1^"
}

Bash experts out there will say “ha, that’s simple”, and it is. Easier than going back again and again in your history to find the command though.

The gfra name is inspired from the zsh git aliases family, and are just initials for git fixup rebase autosquash, just like gs is git status.

Usage

The usage is simple:

gfra <commit-hash>

Automating Commit Fixes with `gfrauto`

While gfra nails the process of fixing and rebasing a single commit, gfrauto takes it a step further – or more like ten – by automating the detection of the commit that modified a particular line in a staged file. No more manual blame, copy-pasting, or rebase editing.

Without further ado, here is the function (zsh syntax for the read commands, so be careful if you use it in bash):

gfrauto() {
  # Fist, display the changes
  git diff --staged

  read "?Continue? ^C to cancel"

  # Extract the line number from the diff
  line=$(git diff --staged --unified=0  | grep -Po '^@@ -[0-9]+(,[0-9]+)? \+\K[0-9]+(,[0-9]+)?(?= @@)');

  # If we have multiple files, arbitrarily pick the first one
  line=$(echo $line | head -1);

  # Line is either a single line or a range of lines
  # E.g. 10 or 10,20
  # If it's a range, we need to split it and get the first line
  line=$(echo $line | cut -d, -f1);

  # Extract the file name from the diff
  file=$(git diff --staged --unified=0 | grep -Po '^\+\+\+ ./\K.*');

  # If we have multiple files, arbitrarily pick the first one
  file=$(echo $file | head -1);

  # Find the commit that last modified the line in the file
  commit=$(git log -u -L $line,$line:$file -1 --pretty=format:"%h" | head -1);

  # Display the hash, the description of the commit for confirmation
  git show --no-patch --format="%h %s" $commit

  read "?Continue? ^C to cancel"

  # Let the magic happen
  gfra $commit
}

Usage

Stage your changes, as usual, keep them light since the script is dumb and will just base its search on the first file it finds. Make sure you only stage changes that belong to the same commit.
Run gfrauto and confirm the diff, then the found commit.
That’s it, it’s fixed up and rebase automatically

The best part is that if your shell history dedupes entries, you won’t ever clutter your history with different calls to the gfra function.

Conclusion

I’ve used gfra for a while and consider it battle tested. The first usage in my zsh history is on dates from more than 5 years ago and I use it multiple times a day. I however don’t pretend to take credit on such a simple function.

For gfrauto, it’s been present as a long one-liner in my history, refined over time. Here is it for posterity:

# Do not use this
gfra $(line=$(gd --staged --unified=0  | grep -Po '^@@ -[0-9]+(,[0-9]+)? \+\K[0-9]+(,[0-9]+)?(?= @@)'); file=$(gd --staged --unified=0 | grep -Po '^\+\+\+ ./\K.*'); git log -u -L $line,$line:$file -1 --pretty=format:"%h" | head -1)

Obviously, it’s more cryptic, handled less edge cases, so I finally took the time to write it down in a more readable form, and I’m happy to share it today.

A simple Sublime Text plugin to copy a file path from the project root

Mon, 11 Mar 2024 12:12:42 +0000

A few days ago, the author of SideBarEnhancements slimmed down his package removing a lot of functionnality. One I used many times per day was the ability to copy a file path from the project root to then use in various commands such as mix test <filepath>, etc.

I wanted to create a standalone plugin that provided similar functionnality. Hopefully, this is quite simple to do:

We’ll need to:

write a Python script that Sublime Text can execute as a plugin
create a command palette entry for it

Creating the Python Plugin

Open Sublime Text and go to Tools > Developer > New Plugin.... This will open a new tab with a template for a new plugin. Then we’ll add the following:

import sublime
import sublime_plugin
import os

class CopyPathFromProjectRootCommand(sublime_plugin.TextCommand):
    def run(self, edit):
        # Get the current file path
        file_path = self.view.file_name()
        if not file_path:
            sublime.status_message("No file to copy path from.")
            return
        
        # Find the project root
        window = self.view.window()
        folders = window.folders()
        project_root = None
        for folder in folders:
            if file_path.startswith(folder):
                project_root = folder
                break
        
        if not project_root:
            sublime.status_message("File is not in any of the loaded projects.")
            return
        
        # Get the relative path from project root and copy it to clipboard
        relative_path = os.path.relpath(file_path, project_root)
        sublime.set_clipboard(relative_path)
        sublime.status_message("Path copied to clipboard: " + relative_path)

Save the file (if you created the file using the above menu, it should already be in the right folder, User).

Creating an entry in the command palette

Create a new file named CopyPathFromProjectRoot.sublime-commands in the same folder, and add the following JSON code to this file:

[
    {
        "caption": "Copy Path From Project Root",
        "command": "copy_path_from_project_root"
    }
]

Usage

You now have a new command in the command palette, Copy Path From Project Root. You can use it to copy the relative path of the current file to the clipboard. That’s it!

You can also bind the command to a key combination, for example:

{
    "keys": ["ctrl+shift+c"],
    "command": "copy_path_from_project_root"
}

(add this to your user keybindings file)

Making IEx react to ^D and ^L (quit and clear) with tmux bindings

Wed, 26 Apr 2023 09:25:46 +0000

I’ve been using tmux for a while now, and I recently started a new position where I’m using Elixir.

I’ve been using it to run IEx, the Elixir REPL. I’ve been annoyed by the fact that IEx doesn’t react to ^D (quit) and ^L (clear screen) like other REPLs do, so I decided look for a solution.

Quitting IEX being almost like quitting Vi, and since the team doesn’t seem to have any intention to change this, I decided to use tmux bindings to make it happen.

I was inspired by this post which uses AutoKey but it only supports X11 and I didn’t like the idea of interfacing too far away from the terminal.

As it’s not possible to add key bindings directly at the shell level, the next best thing is to use tmux bindings.

I added the following lines to my .tmux.conf:

bind -n C-d if -F "#{m:*iex*,#{pane_title}}" 'send-keys C-\\' "send-keys C-d"
bind -n C-l if -F "#{m:*iex*,#{pane_title}}" 'send-keys clear\n' "send-keys C-l"

All it does is checking that the current pane runs iex, and if so, it sends the appropriate key sequence.

C-\ is the sequence for quitting iex
clear\n is the sequence for clearing the screen

If the pane doesn’t run iex, it just sends the unmodified key sequence.

I’m pretty happy with the result, and I hope it can help someone else.

How to remove trailing slash on Jekyll with Cloudflare

Mon, 09 Jan 2023 10:02:42 +0000

Previously all my blog posts were served from Github pages with a trailing slash, for example:

https://saveman71.com/2023/some-article/

This is because the permalink setting of Jekyll had a trailing slash included. Wanting to change that for cleanliness and ✨SEO reasons✨, I made the following change a few days ago:

All was well, until I learnt via Google’s search console that I had more and more 404s. This guide came in handy in identifying the culprit: GitHub pages doesn’t do anything about trailing slashes. If it’s there, it considers it a directory and looks for an index.html file in there. Since the change was made, files were now some-article.html and not some-article/index.html, thus the 404s.

This could just be left alone and it could probably fix itself, Google would quicly notice that and remove the old pages, index the new ones; etc. But for, again, SEO reasons, it’s best to properly “migrate” the pages with a 301 redirect, so the SEO of each page isn’t lost in the process.

Unfortunately, neither GH pages or Jekyll (unless resorting to ugly techniques such as creating the directories, adding meta redirects there, etc.) can actually do these redirects themselves. That’s where Cloudflare comes in. Not the ideal solution, but for such a small “fix”, it’s practical and not an actual dependency.

I couldn’t find a blog article that would explain how to solve that problem, that’s why I’m writing this!

Enough talk, let’s get down to business. So you have your CF property, go to URL rules, create a new rule, and:

URL: https://example.com/*/

Destination URL: https://example.com/$1

TADAA!

This was also (briefly) posted as answers to Stack Overflow here and here.

[FR] A Jeune Conducteur PDF

Mon, 02 Jan 2023 11:20:42 +0000

Note: This article in french differs from what I usually post there. But IMO it's also sharing knowledge, and is only relevant for french speakers.

En France, les jeunes conducteurs sont obligés de placer un disque A à l’arrière gauche de leur véhicule.

Ce disque doit être affiché pendant 3 ans pour les conducteurs ayant suivi un cursus classique, et pendant 2 ans pour ceux ayant effectué la conduite accompagnée.

Si un jeune conducteur se fait contrôler sans ce disque, il doit payer une amende de 35 euros.

Voici donc une version faite par mes soins qui ne contient pas de publicité, pas de frioriture, juste le A sur une feuille A4 (à imprimer à l’échelle bien sûr) en format PDF.

en format PDF (à imprimer A4) en SVG (fichier source)

Plastifiez-le et appliquez le à l’aide de double face sur l’arrière gauche du vehicule. Notez que l’affichage sur le par-brise arrière est à priori interdit.

Le disque A doit être une version homologuée: les versions dessinées à la main ne sont pas autorisées, l’homologation est la suivante (Arrêté du 5 mai 1994) :

Antoine Bolvy

HiDPI Electron <37 apps on Sway

Do not store your translations in Git

(Almost) everything in Git

The Problem: Compile-Time Complexity

Why we stuck with this workflow for so long

The Eureka Moment

The Solution: Extract On Demand

Conclusion

Cleaning up local branches after squash merges

The Problem: Squash Merges Break Everything

A Better Solution

Step 1: Find Remote Branches That Were Deleted

Step 2: Verify Before Deleting

Safety Features

The Complete Script

Fixing Flaky Elixir Tests with Randomized Query Ordering

The Problem: Unstable Sorting in Database Queries

A proposed solution: Enforcing Randomness

Finding All the Flaky Tests

Fixing the Tests

The Results

Conclusion

Local Elixir development with ASDF

Local development of Elixir with ASDF

Configuring asdf

Testing

Streamlining `git commit --fixup` and `git rebase --autosquash` with `gfrauto`

Intro

Automated fixup with gfra

Usage

Automating Commit Fixes with gfrauto

Usage

Conclusion

A simple Sublime Text plugin to copy a file path from the project root

Creating the Python Plugin

Creating an entry in the command palette

Usage

Making IEx react to ^D and ^L (quit and clear) with tmux bindings

How to remove trailing slash on Jekyll with Cloudflare

[FR] A Jeune Conducteur PDF

Configuring `asdf`

Automated fixup with `gfra`

Automating Commit Fixes with `gfrauto`