Glauco Custodio

A Neat Trick for Splitting Strings

Thu, 15 Jan 2026 00:00:00 -0300

You probably needed to split a full name into first and last name at some point.

How would you split the string Ayrton Senna da Silva into Ayrton as the first name and Senna da Silva as the last name?

What if the name contains inconsistent amounts of whitespace in between the words? Eg: Ayrton Senna da Silva.

"Ayrton Senna da  Silva".split(" ")
# => ["Ayrton", "Senna", "da", "Silva"]

Splitting by space is a good start, but it doesn't finish the job.

Solution

I learned recently we can pass a second argument to split specifying the maximum number of splits:

"Ayrton Senna da  Silva".split(" ", 2)
# => ["Ayrton", "Senna da  Silva"]

That almost worked, but we still have an extra space in the last name.

By combining it with squish we can get the desired result in a clean way:

"Ayrton Senna da  Silva".squish.split(" ", 2)
# => ["Ayrton", "Senna da Silva"]

That's it.

RSpec Satisfy Matcher

Fri, 02 Jan 2026 00:00:00 -0300

I've recently discovered (or at least found a good use case for it) the satisfy matcher in RSpec.

My intention was to ensure an attribute contained a string and not another string (within have_attributes).

I tried a few variations of the code below, but none of them worked:

message = Message.first
expect(message).to have_attributes(
  conversation_id: conversation.id,
  customer: "customer@example.com",
  response: include("Hello, world!").and(not_to(include("Subject:")))
)

While inspecting rspec-expectations's source code in search of an exclude matcher or something similar, the satisfy matcher stood out as a good fit:

expect(message).to have_attributes(
  conversation_id: conversation.id,
  customer: "customer@example.com",
  response: satisfy do |response|
    response.include?("Hello, world!") && !response.include?("Subject:")
  end
)

It's pretty self-explanatory, isn't it? The test will pass if the block returns true.

New in Rails 8.1: Bring Your Favorite Editor to Error Pages

Thu, 20 Nov 2025 00:00:00 -0300

Rails 8.1.0 (released on October 22, 2025) brings a new feature that allows you to open the file that caused the error in your favorite editor.

To enable this feature, you need to set either EDITOR or RAILS_EDITOR environment variable with the path to your editor, for example:

# .bashrc / .zshrc
export RAILS_EDITOR="cursor"

Then, when you are taken to the error page, click on the pencil icon to open it in your editor:

A new ActiveSupport::Editor class has been added to handle the editor functionality, check the pull request for more details.

TIL: previously_new_record? — A Hidden Gem in ActiveRecord

Thu, 03 Jul 2025 00:00:00 -0300

Have you ever needed to know if a record in Rails was just created — especially after using create_or_find_by or find_or_create_by?

Most Rails devs reach for new_record?, but it won’t help after create_or_find_by, because the record is already saved. So how do you know if a record was just created?

Say hello to previously_new_record?, which for my surprise is available since Rails 6.1.

It tells you if the record was new right before the last save — giving you a clean way to trigger onboarding logic, log metadata, or set defaults only for new records.

Here's how one can use it:

user = User.create_or_find_by(email: params[:email])

# only create the log if the user was just created
if user.previously_new_record?
  create_log(user)
end

Next time you need to distinguish between a found and a created record, reach for previously_new_record?. It’s already part of ActiveRecord — no extra setup needed.

You can check out how it was implemented in this pull request.

New in Rails 8: Bring Your Favorite CLI to rails dbconsole

Wed, 21 May 2025 00:00:00 -0300

Rails 8 got even better for developers who love clean CLI workflows.

You can now customize the command-line tool used by rails dbconsole with the new config.active_record.database_cli setting.

Prefer pgcli over the default psql to connect to your database? Make your dev experience smoother with autocomplete and syntax highlighting:

# config/initializers/database_cli.rb
Rails.application.configure do
  if Rails.env.local?
    config.active_record.database_cli = {postgresql: "pgcli"}
  end
end

Available since Rails 8.0.0.beta1 — check out the pull request for full details and start customizing your database workflow today.

Migrating From Dokku to Kamal: Scheduling Cron Jobs

Tue, 23 Jan 2024 00:00:00 -0300

This is the third post of the series "Migrating From Dokku to Kamal" and today I am gonna show you how I've set cron with Kamal, click here to read the second post of the series in case you've missed it.

I needed a way run periodic tasks on Kamal to replace Dokku's scheduled cron tasks.

Cron seemed the way to go according to this pull request on the Kamal repo, but making it work turned out to be not so simple as that.

The idea is to have a new container on the worker server responsible for scheduling jobs defined on a crontab file.

Defining cron jobs

First thing is to create this crontab file defining the tasks to be scheduled by cron, I've put this file on config/app.crontab:

59 20 * * 1,2,3,4,5 /rails/bin/cron-executor.sh make whatever

Note that I am passing the command I want to run (make whatever in this case) to a bin/cron-executor.sh:

#!/bin/bash -e

PATH=$PATH:/usr/local/bin

cd /rails || exit

echo "CRON: ${@}" >/proc/1/fd/1 2>/proc/1/fd/2

exec "${@}" >/proc/1/fd/1 2>/proc/1/fd/2

this shell script is responsible for doing a few things before running the desired command:

adds /usr/local/bin to $PATH, so ruby and bundle can be loaded
enters the directory of the application (/rails)
prints the command that is about to be executed
executes the command

In case you are wondering, >/proc/1/fd/1 2>/proc/1/fd/2 is required to redirect the output of the command to the container's stdout/stderr. If you don't add this, you won't be able to see the logs of the cron jobs when running docker logs for example.

Setting up the Dockerfile

The next step is to make sure the application's Dockerfile installs cron and applies the jobs from the crontab file we just defined:

ARG RUBY_VERSION=3.2.2
FROM ruby:$RUBY_VERSION-slim-bullseye as base

...

RUN apt-get update \
    && DEBIAN_FRONTEND=noninteractive apt-get -y --no-install-recommends install -y cron \
    # Remove package lists for smaller image sizes
    && rm -rf /var/lib/apt/lists/* \
    && which cron \
    && rm -rf /etc/cron.*/*

COPY config/app.crontab /etc/cron.d/cronfile
RUN chmod 0644 /etc/cron.d/cronfile
RUN crontab /etc/cron.d/cronfile

USER root

ENTRYPOINT ["/rails/bin/docker-entrypoint"]

EXPOSE 3000
CMD ["./bin/rails", "server"]

The default Dockerfile for Rails 7.1 sets up a non-root user for security reasons, but I couldn't get cron working with a non-root user, that's why I ended up using USER root. Please let me know in case you managed to get that working.

Passing environment variables to cron

Cron reads environment variables from /etc/environment, so we need to set them there by adding one line to bin/docker-entrypoint:

#!/bin/bash -e

# pass env vars to cron
env >> /etc/environment

# If running the rails server then create or migrate existing database
if [ "${1}" == "./bin/rails" ] && [ "${2}" == "server" ]; then
  ./bin/rails db:prepare
fi

exec "${@}"

Defining a new server

The last step is to define a new server on Kamal's deploy.yml with the same ip as the worker:

servers:
  web:
    hosts:
      - <%= ENV['KAMAL_WEB_IP'] %>
    labels:
      traefik.http.routers.domain.rule: Host(`*.domain.com`)
      traefik.http.routers.domain.entrypoints: websecure
      traefik.http.routers.domain.tls.certresolver: letsencrypt

  worker:
    hosts:
      - <%= ENV['KAMAL_WORKER_IP'] %>
    cmd: bin/run-worker.sh

  cron:
    hosts:
      - <%= ENV['KAMAL_WORKER_IP'] %>
    cmd: bash -c "cron -f -L 2"

Note that bash -c "cron -f -L 2" is set as the command to run on the container, it'll make cron to run on the foreground and set the logging verbosity.

That's all folks, I hope you have enjoyed the series.

Ps: I'd like to thank you Jason for writing this post on running cron on Docker, it was really useful to me!

Migrating From Dokku to Kamal: Setting up the Servers

Fri, 19 Jan 2024 00:00:00 -0300

This is the second post of the series "Migrating From Dokku to Kamal" and today I am gonna show you how I've set up my servers with Kamal, click here to read the first post of the series in case you've missed it.

The author assumes you've a basic understanding of how Kamal works, you can familiarize yourself by checking the official documentation.

Below you can find part of my final deploy.yml:

servers:
  web:
    hosts:
      - <%= ENV['KAMAL_WEB_IP'] %>
    labels:
      traefik.http.routers.domain.rule: Host(`*.domain.com`)
      traefik.http.routers.domain.entrypoints: websecure
      traefik.http.routers.domain.tls.certresolver: letsencrypt

  worker:
    hosts:
      - <%= ENV['KAMAL_WORKER_IP'] %>
    cmd: bin/run-worker.sh

  registry:
    server: ghcr.io
    username: your_github_username
    password:
      - KAMAL_REGISTRY_PASSWORD

env:
  clear:
    RAILS_ENV: production
    PIDFILE: /dev/null
  secret:
    - RAILS_LOG_TO_STDOUT
    - CLOUDFLARE_API_KEY
    - S3_ACCESS_KEY_ID
    - S3_SECRET_ACCESS_KEY
    - S3_ENDPOINT
    - S3_REGION
    - POSTGRES_DATABASE
    - POSTGRES_HOST
    - POSTGRES_DB
    - POSTGRES_USER
    - POSTGRES_PASSWORD

builder:
  multiarch: false

accessories:
  db:
    image: postgres:16.0
    host: <%= ENV['POSTGRES_HOST'] %>
    port: 5432
    env:
      secret:
        - POSTGRES_DB
        - POSTGRES_USER
        - POSTGRES_PASSWORD
    directories:
      - data:/var/lib/postgresql/data

  db_backup:
    image: eeshugerman/postgres-backup-s3:16
    host: <%= ENV['POSTGRES_HOST'] %>
    env:
      clear:
        SCHEDULE: '@daily'
        BACKUP_KEEP_DAYS: 10
        S3_BUCKET: whatever-bucket
        S3_PREFIX: backups
      secret:
        - S3_ACCESS_KEY_ID
        - S3_SECRET_ACCESS_KEY
        - S3_ENDPOINT
        - S3_REGION
        - POSTGRES_HOST
        - POSTGRES_DATABASE
        - POSTGRES_USER
        - POSTGRES_PASSWORD

traefik:
  options:
    publish:
      - "443:443"
    volume:
      - "/letsencrypt/acme.json:/letsencrypt/acme.json"
  args:
    entryPoints.web.address: ":80"
    entryPoints.websecure.address: ":443"
    entryPoints.web.http.redirections.entryPoint.to: websecure
    entryPoints.web.http.redirections.entryPoint.scheme: https
    entryPoints.web.http.redirections.entrypoint.permanent: true
    entrypoints.websecure.http.tls: true
    entrypoints.websecure.http.tls.domains[0].main: "domain.com"
    entrypoints.websecure.http.tls.domains[0].sans: "*.domain.com"
    certificatesResolvers.letsencrypt.acme.email: "user@provider.com"
    certificatesResolvers.letsencrypt.acme.storage: "/letsencrypt/acme.json"
    certificatesresolvers.letsencrypt.acme.dnschallenge.provider: cloudflare
  env:
    secret:
      - CLOUDFLARE_API_KEY
    clear:
      CLOUDFLARE_EMAIL: 'user@provider.com'

It does a couple of things:

reads the env vars KAMAL_WEB_IP, KAMAL_WORKER_IP and POSTGRES_HOST from the .env file that were defined with Terraform (as shown on the other post)
defines three servers: web, worker and db (which is under accessories)
sets Let's Encrypt as certificate resolver for the web server
overrides the command to be executed on the Docker container for the worker server, it'll run bin/run-worker.sh instead
sets GitHub as image registry, it's for free
sets env vars. PIDFILE=/dev/null tells Rails to not save pid files as you might receive the error A server is already running. Check /rails/tmp/pids/server.pid in case docker gets killed abruptly. This will be the default behaviour as of Rails 8. Check this post for more info.
speeds up the build time by disabling multiarch since both my local machine and the servers run on the arm64 architecture
sets up a container on the db server to backup the Postgres database once a day using postgres-backup-s3

Resolving Let's Encrypt ACME v2 challenge

As my domain has Cloudflare as DNS resolver and I wanted to support wildcard certificates - so I could test my app at kamal.domain.com before switching from Digital Ocean to Hetzner on domain.com, the web server is solving Let's Encrypt ACME v2 challenge through DNS (thanks Nick for sharing it), that's why I had to define the extra args for traefik (including CLOUDFLARE_EMAIL and CLOUDFLARE_API_KEY).

Note we are storing the certificate on the file we created with Terraform: /letsencrypt/acme.json. This way we don't need to regenerate a new certificate every time a new web container is run.

That's it for today, in the last post of the series I share how I've set up cron to run scheduled tasks.

Migrating From Dokku to Kamal: Provisioning with Terraform

Thu, 18 Jan 2024 00:00:00 -0300

I have a 2 GB Memory, 1 vCPU, 50 GB Disk VPS on Digital Ocean which cost me 12 USD per month. Comparing the prices with Hetzner I noticed I could have 3x 4 GB, 2 vCPU Arm64, 40 GB Disk for 13.53 EUR per month. That's a lot more power for almost the same price.

The droplet is running a Rails application with Dokku. I really enjoyed my time with Dokku, it makes our lives so much easier when setting up a VPS from scratch. The major downside of Dokku is the lack of support to multi-host though.

After the introduction of Kamal I thought in giving it a try, but this time using Hetzner instead of Digital Ocean.

Provisioning Resources on Hetzner with Terraform

Since I would be creating new servers on Hetzner, I asked ChatGPT to help me doing that with Terraform so the whole process could be easily repeatable.

After some back and forth I ended up with the following script on terraform/main.tf:

# requires TF_VAR_hetzner_api_token env var
# eg: `TF_VAR_hetzner_api_token=foo terraform apply`
variable "hetzner_api_token" {
  type    = string
  default = ""
}

# requires TF_VAR_hetzner_ssh_fingerprint env var
# eg: `TF_VAR_hetzner_ssh_fingerprint=bar terraform apply`
variable "hetzner_ssh_fingerprint" {
  type    = string
  default = ""
}

# requires TF_VAR_user_private_key_path env var
# eg: `TF_VAR_user_private_key_path=/Users/foo/.ssh/id_ed25519 terraform apply`
variable "user_private_key_path" {
  type    = string
  default = ""
}

variable "server_names" {
  default = ["web", "worker", "db"]
}

data "hcloud_ssh_key" "ssh_key" {
  fingerprint = var.hetzner_ssh_fingerprint
}

provider "hcloud" {
  token = var.hetzner_api_token
}

variable "common_provisioner_commands" {
  # change default DNS servers as Hetzner's default ones are not reliable
  default = [
    "echo 1",
    "sed -i 's/#DNS=/DNS=1.1.1.1/' /etc/systemd/resolved.conf",
    "sed -i 's/#FallbackDNS=/FallbackDNS=8.8.8.8/' /etc/systemd/resolved.conf",
    "sed -i 's/#DNSOverTLS=no/DNSOverTLS=opportunistic/' /etc/systemd/resolved.conf",
    "systemctl restart systemd-resolved",
  ]
}

resource "hcloud_server" "cax11" {
  count       = length(var.server_names)
  name        = var.server_names[count.index]
  image       = "ubuntu-22.04"
  server_type = "cax11"
  location    = "nbg1"
  ssh_keys    = [data.hcloud_ssh_key.ssh_key.id]

  public_net {
    ipv4_enabled = true
    ipv6_enabled = true
  }

  # create a acme.json file only on the server "web"
  # it will be used to keep the certificate on the host so it can be reused
  # across many containers (will avoid rate limiting from letsencrypt)
  #
  # inspiration: https://github.com/basecamp/kamal/discussions/112#discussioncomment-6266858
  #
  provisioner "remote-exec" {
    inline = var.server_names[count.index] == "web" ? concat([
      "mkdir -p /letsencrypt && touch /letsencrypt/acme.json && chmod 600 /letsencrypt/acme.json",
    ], var.common_provisioner_commands) : var.common_provisioner_commands

    connection {
      type        = "ssh"
      user        = "root"
      private_key = file(var.user_private_key_path)
      host        = self.ipv4_address
    }
  }
}

# Print the IP addresses of the created instances
output "formatted_instance_ips" {
  value = <<-EOT
    web: ${hcloud_server.cax11[0].ipv4_address}
    worker: ${hcloud_server.cax11[1].ipv4_address}
    db: ${hcloud_server.cax11[2].ipv4_address}
  EOT
}


# update ../.env file with IPv4 addresses and
# remove old ssh keys from the .ssh/known_hosts file
resource "null_resource" "update_env_file" {
  depends_on = [hcloud_server.cax11]

  provisioner "local-exec" {
    command = <<EOT
sed -i -E 's/^KAMAL_WEB_IP=.*/KAMAL_WEB_IP=${hcloud_server.cax11[0].ipv4_address}/' ../.env
sed -i -E 's/^KAMAL_WORKER_IP=.*/KAMAL_WORKER_IP=${hcloud_server.cax11[1].ipv4_address}/' ../.env
sed -i -E 's/^POSTGRES_HOST=.*/POSTGRES_HOST=${hcloud_server.cax11[2].ipv4_address}/' ../.env
ssh-keygen -R ${hcloud_server.cax11[0].ipv4_address}
ssh-keygen -R ${hcloud_server.cax11[1].ipv4_address}
ssh-keygen -R ${hcloud_server.cax11[2].ipv4_address}
EOT
  }
}

terraform {
  required_version = ">= 1.4.3"
  required_providers {
    hcloud = {
      "source"  = "hetznercloud/hcloud"
      "version" = ">= 1.44.1"
    }
  }
}

The script above does a couple of things:

define a few variables so the Terraform script doesn't hold any hard coded sensitive data, namely the Hetzner api token, the fingerprint of the ssh key associated with my account on Hetzner and my ssh private key
define the resources to be managed on the german provider: 3 VPSs of the type CAX11, named web, worker and db
create and give permission to the file /letsencrypt/acme.json only on the web server as it will be used ahead to hold Let's Encrypt certificate
change default DNS and enable DNSOverTLS when supported
print the ipv4 of the created resources
update the .env file with the ipv4 of the created servers. This file will be used by Kamal to set up the environment variables on the servers
remove the ipv4 of the created resources from the .ssh/known_hosts file, this can be left out in case you are not applying and destroying the resources on Hetzner often.
define the versions of Terraform and the provider (boilerplate code required by Terraform)

Once you have uploaded your public ssh key to Hetzner, you can copy the fingerprint by visiting Security -> SSH keys on their website.

By visiting Security -> API tokens you can generate an api token that will allow Terraform to manage resources on your Hetzner account.

The path to your private key is required so Terraform can ssh into the servers on your behalf.

Once you have everything in place and have installed Terraform on your machine you can run:

cd terraform
terraform init

to initialize the terraform thing and:

TF_VAR_user_private_key_path=/Users/my_user/.ssh/id_ed25519 TF_VAR_hetzner_api_token="abcdefghijklmnopqrstuvwxyz" TF_VAR_hetzner_ssh_fingerprint="a1:b2:c3:d4:e5:f6:g7:h8" terraform apply

to create the resources on Hetzner. Notice you gotta prepend TF_VAR_ on the name of the variables defined in the script.

In case you want to destroy the resources created you can run:

TF_VAR_user_private_key_path=/Users/my_user/.ssh/id_ed25519 TF_VAR_hetzner_api_token="abcdefghijklmnopqrstuvwxyz" TF_VAR_hetzner_ssh_fingerprint="a1:b2:c3:d4:e5:f6:g7:h8" terraform destroy

In the next post of the series I share how Kamal has been used to set up the servers, including Let's Encrypt on the web.

Turbo Drive + ECharts: Fixing History Back

Mon, 03 Apr 2023 00:00:00 -0300

Problem

You got a Rails app with Turbo Drive and some charts powered by ECharts.

It works fine until you navigate to another page and hit the back button.

When navigating back in the browser history, somehow Turbo can't deal with the charts and displays an empty square instead of rendering them. Only a full page refresh can make them appear again.

The Lazy Solution

The simpler (but not so nice) solution is to disable Turbo Drive for all links on that particular page which contains the charts:

<head>
  ...
  <meta name="turbo-visit-control" content="reload">
</head>

But that would downgrade the user experience, so it's kinda meh.

A Better Solution

Turbo Drive caches the current page before requesting the clicked link, so I thought, what if I dispose the charts before saving the cache?

That worked.

We can use the turbo:before-cache callback to remove all chart instances upon navigation:

let allChartIntances = []

document.addEventListener('turbo:before-cache', function() {
  allChartIntances.forEach(chartInstance => chartInstance.dispose())
})

document.addEventListener('turbo:load', function() {
  let fooChart = echarts.init(fooContainer);
  allChartIntances.push(fooChart)

  let barChart = echarts.init(barContainer);
  allChartIntances.push(barChart)
})

In the example above two charts are created and stored in the allChartInstances array when the page first load. Before caching the page they are properly removed and when navigating back they will be re-created on turbo:load.

How to Install Multiple Versions of Python on Apple Silicon / M1

Fri, 14 Oct 2022 00:00:00 -0300

I struggled to build and install Python on M1. Only got this error configure: error: Unexpected output of 'arch' on OSX.

I had Homebrew and asdf installed for arm64 (default Apple Silicon / M1 architecture).

That's what worked for me: duplicate iTerm (Finder -> Applications -> Right click on iTerm -> Duplicate) and set it to run with Rosetta (Right click on the duplicated iTerm -> Get Info -> Mark "Open using Rosetta").

Rename the duplicate to something like iTerm Rosetta and you will end up with iTerm and iTerm Rosetta.

Open iTerm Rosetta and type arch, it must show i386 on iTerm Rosetta and arm64 on regular iTerm.

Install Homebrew on i386. Open iTerm Rosetta and run /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)", then which brew to confirm, you must see /usr/local/bin/brew.

Homebrew for arm64 is installed on /opt/homebrew/bin/brew instead.

Now install the desired version of Python using asdf, eg: asdf install python 3.8.9.