Ruby & Beyond

Where is the software development industry going?

Tue, 21 Oct 2025 00:00:00 +0400

What does the future of software development actually look like—and where does AI fit in?

Kamal 2 – Get out of the cloud

Sat, 17 May 2025 00:00:00 +0400

I took the TropicalOnRails 2025 stage to challenge the status quo with the talk “Kamal 2 – Get Out of Cloud”. In this bold session, I explored the possibilities and implications of running your infrastructure without relying on traditional cloud providers. Drawing from real-world experience and practical experimentation, I unpacked the motivations behind adopting Kamal 2, the architectural decisions involved, and what this shift means for scalability, cost, and developer control. A compelling talk for anyone curious about modern deployment strategies beyond the cloud.

Kamal cheat sheet

Thu, 17 Apr 2025 00:00:00 +0400

I use Kamal daily to deploy all the apps I maintain. I created a list of Kamal commands I use frequently. While this is not an exhaustive list, but it covers the most common tasks I usually perform.


# The init command is used to create the config and secrets files once after Kamal is added to the app.
$ kamal init

# Install Docker on all target hosts
$ kamal server

# Aliases
# Kamal defines `kamal shell` out of the box, I usually add `kamal console` to quickly access the Rails console.
$ kamal shell [-d production]
# app exec -i --reuse "bin/rails console"
$ kamal console [-d production]

# Deploy app [to the staging environment]
$ kamal deploy [-d staging]

# Rollback app [to the VERSION] [in the staging environment]
$ kamal rollback [VERSION] [-d staging]

# Building images
# Most of the time you won't use the `kamal build` command directly,
# since it primarily used by `kamal deploy` and `kamal redeploy`.
# However, you can also use it to build the app image without pushing it, which is useful for testing.
$ kamal build dev

# Below are several commands to read the logs of the app and its accessories.
$ kamal app logs [--roles=web -n 100 -f]
$ kamal app logs [--primary -n 100 -f]
$ kamal app logs [--hosts=<ip_address> -n 100 -f]
$ kamal audit
# Show logs for the PgHero accessory [for the staging environment]
$ kamal accessory logs pghero [-d staging]
# Show logs for the proxy server [for the staging environment]
$ kamal proxy logs [-d staging]

# Show combined config (including secrets) [for the staging environment]. Can be useful to debug and in case you forgot your server ip-address.
$ kamal config [-d staging]

# Print secrets to stdout [for the staging environment]
$ kamal secrets print [-d staging]

# Show details about all containers grouped by role [for the staging environment]
$ kamal details [-d staging]

# Show details only about the app containers [for the staging environment], [for the web role]
$ kamal app details [-d staging] [--roles=web]

# Show details only about the PgHero accessory containers [for the staging environment]
$ kamal accessory details pghero -d staging

To see all available commands, run kamal help. If you prefer to save this cheat sheet as an image, use this link.

Rails Dockerfile Best Practices – Part 1: Image Slimming

Tue, 28 Jan 2025 00:00:00 +0400

This article is a part of a series of posts where I will walk through every line of the Rails default Dockerfile and explain the best practices and optimizations.

Docker images can be optimized in different ways that include, but are not limited to, image size reduction, build performance optimization, security, and maintainability best practices, and application-specific optimizations. In the first article, I will touch only image size reduction optimization and explain why they are important.

Why to optimize the image size?

As in every other process of software development, each developer will list his reasons why he wants to make his Docker builds faster. I will list the reasons that are most important to me.

Faster builds & deployments

Smaller images are faster to build because fewer files and layers need to be processed. This improves developer productivity, especially during iterative development cycles. Smaller images take less time to push to a registry and pull from it during deployments. This is especially critical in CI/CD pipelines where containers are built and deployed frequently.

Reduced storage costs & network bandwidth usage

Smaller images consume less storage on container registries, local development machines, and production servers. This reduces infrastructure costs, especially for large-scale deployments. Smaller images use less bandwidth when transferred between servers, especially important when you’re building images locally or in CI/CD pipelines and pushing them to a registry.

We spent $3.2m on cloud in 2022... We stand to save about $7m in server expenses over five years from our cloud exit.

David Heinemeier Hansson — HEY World

Improved performance & security

Smaller images require fewer resources (e.g., CPU, RAM) to load and run, improving the overall performance of containerized applications. Faster startup times mean your services are ready more quickly, which is crucial for scaling and high-availability systems. Minimal base images like alpine or debian-slim contain fewer pre-installed packages, decreasing the risk of unpatched or unnecessary software being exploited.

Besides everything mentioned above, removing unnecessary files and tools minimizes distractions when diagnosing issues and leads to better maintainability and reduced technical debt.

Inspecting Docker images

To get different parameters of the image, including the the size, you can either look at the Docker Desktop or run the docker images command in the terminal.


➜ docker images
REPOSITORY        TAG       IMAGE ID       CREATED        SIZE
kamal-dashboard   latest    673737b771cd   2 days ago     619MB
kamal-proxy       latest    5f6cd8983746   6 weeks ago    115MB
docs-server       latest    a810244e3d88   6 weeks ago    1.18GB
busybox           latest    63cd0d5fb10d   3 months ago   4.04MB
postgres          latest    6c9aa6ecd71d   3 months ago   456MB
postgres          16.4      ced3ad69d60c   3 months ago   453MB

Knowing the size of the image does not give you the full picture. You don’t know what is inside the image, how many layers it has, or how big each layer is. A Docker image layer is a read-only, immutable file system layer that is a component of a Docker image. Each layer represents a set of changes made to the image’s file system, such as adding files, modifying configurations, or installing software.

Docker images are built incrementally, layer by layer, and each layer corresponds to an instruction in the Dockerfile. To get the layers of the image, you can run the docker history command.


➜ docker history kamal-dashboard:latest
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
673737b771cd   4 days ago    CMD ["./bin/thrust" "./bin/rails" "server"]     0B        buildkit.dockerfile.v0
<missing>      4 days ago    EXPOSE map[80/tcp:{}]                           0B        buildkit.dockerfile.v0
<missing>      4 days ago    ENTRYPOINT ["/rails/bin/docker-entrypoint"]     0B        buildkit.dockerfile.v0
<missing>      4 days ago    USER 1000:1000                                  0B        buildkit.dockerfile.v0
<missing>      4 days ago    RUN /bin/sh -c groupadd --system --gid 1000 …   54MB      buildkit.dockerfile.v0
<missing>      4 days ago    COPY /rails /rails # buildkit                   56.2MB    buildkit.dockerfile.v0
<missing>      4 days ago    COPY /usr/local/bundle /usr/local/bundle # b…   153MB     buildkit.dockerfile.v0
<missing>      4 days ago    ENV RAILS_ENV=production BUNDLE_DEPLOYMENT=1…   0B        buildkit.dockerfile.v0
<missing>      4 days ago    RUN /bin/sh -c apt-get update -qq &&     apt…   137MB     buildkit.dockerfile.v0
<missing>      4 days ago    WORKDIR /rails                                  0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   CMD ["irb"]                                     0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c set -eux;  mkdir "$GEM_HOME";…   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV PATH=/usr/local/bundle/bin:/usr/local/sb…   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV BUNDLE_SILENCE_ROOT_WARNING=1 BUNDLE_APP…   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV GEM_HOME=/usr/local/bundle                  0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c set -eux;   savedAptMark="$(a…   78.1MB    buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV RUBY_DOWNLOAD_SHA256=018d59ffb52be3c0a6d…   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV RUBY_DOWNLOAD_URL=https://cache.ruby-lan…   0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV RUBY_VERSION=3.4.1                          0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   ENV LANG=C.UTF-8                                0B        buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c set -eux;  mkdir -p /usr/loca…   19B       buildkit.dockerfile.v0
<missing>      3 weeks ago   RUN /bin/sh -c set -eux;  apt-get update;  a…   43.9MB    buildkit.dockerfile.v0
<missing>      3 weeks ago   # debian.sh --arch 'arm64' out/ 'bookworm' '…   97.2MB    debuerreotype 0.15

Since I already provided theory about images, and layers, it is time to explore the Dockerfile. Starting from Rails 7.1, the Dockerfile is generated with the new Rails application. Below is an example of what it may look like.


# syntax=docker/dockerfile:1
# check=error=true

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
ARG RUBY_VERSION=3.4.1
FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

# Rails app lives here
WORKDIR /rails

# Install base packages
# Replace libpq-dev with sqlite3 if using SQLite, or libmysqlclient-dev if using MySQL
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Set production environment
ENV RAILS_ENV="production" \
    BUNDLE_DEPLOYMENT="1" \
    BUNDLE_PATH="/usr/local/bundle" \
    BUNDLE_WITHOUT="development"

# Throw-away build stage to reduce size of final image
FROM base AS build

# Install packages needed to build gems
RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y build-essential curl git pkg-config libyaml-dev && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

# Install application gems
COPY Gemfile Gemfile.lock ./
RUN bundle install && \
    rm -rf ~/.bundle/ "${BUNDLE_PATH}"/ruby/*/cache "${BUNDLE_PATH}"/ruby/*/bundler/gems/*/.git && \
    bundle exec bootsnap precompile --gemfile

# Copy application code
COPY . .

# Precompile bootsnap code for faster boot times
RUN bundle exec bootsnap precompile app/ lib/

# Precompiling assets for production without requiring secret RAILS_MASTER_KEY
RUN SECRET_KEY_BASE_DUMMY=1 ./bin/rails assets:precompile

# Final stage for app image
FROM base

# Copy built artifacts: gems, application
COPY --from=build "${BUNDLE_PATH}" "${BUNDLE_PATH}"
COPY --from=build /rails /rails

# Run and own only the runtime files as a non-root user for security
RUN groupadd --system --gid 1000 rails && \
    useradd rails --uid 1000 --gid 1000 --create-home --shell /bin/bash && \
    chown -R rails:rails db log storage tmp
USER 1000:1000

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"]

Below I will provide a list of approaches and rules that where applied to the Dockerfile above to make the final image size efficient.

Optimize packages installations

I am sure you keep only needed software on your local development machine. The same should be applied to Docker images. In the examples below I will consistently making worse the Dockerfile extracted from the Rails Dockerfile above. I will reference it as an original Dockerfile version.

Rule #1: Use minimal base images


FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

The base image is the starting point for the Dockerfile. It is the image that is used to create the container. The base image is the first layer in the Dockerfile, and it is the only layer that is not created by the Dockerfile itself.

The base image is specified with the FROM command, followed by the image name and tag. The tag is optional, and if not specified, the latest tag is used. The base image can be any image available on Docker Hub or any other registry.

In the Dockerfile about, we are using the ruby image with the 3.4.1-slim tag. The ruby image is the official Ruby image available on Docker Hub. The 3.4.1-slim tag is a slim version of the Ruby image that is based on the debian-slim image. While the debian-slim image is a minimal version of the Debian Linux image that is optimized for size. Look at the table below to get an idea of how smaller the slim image is.


➜ docker images --filter "reference=ruby"
REPOSITORY   TAG              IMAGE ID       CREATED      SIZE
ruby         3.4.1-slim       0bf957e453fd   5 days ago   219MB
ruby         3.4.1-alpine     cf9b1b8d4a0c   5 days ago   99.1MB
ruby         3.4.1-bookworm   1e77081540c0   5 days ago   1.01GB

Debian Releases

As of January, 2024, current Debian release is called bookworm and the previous one is bullseye.

219 MB instead of 1GB — a huge difference. But what if the alpine image is even smaller? The alpine image is based on the Alpine Linux distribution, which is a super lightweight Linux distribution that is optimized for size and security. Alpine uses the musl library (instead of glibc) and busybox (a compact set of Unix utilities) instead of GNU counterparts. While it is technically possible to use the alpine image to run Rails, I will not cover it in this article.

Rule #2: Minimize layers


RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev && \
    rm -rf /var/lib/apt/lists /var/cache/apt/archives

Each RUN, COPY and FROM instruction in Dockerfile creates a new layer. The more layers you have, the bigger the image size. This is why the best practice is to combine multiple commands into a single RUN instruction. To illustrate this point, let’s look at the example below.


# syntax=docker/dockerfile:1
# check=error=true

# Make sure RUBY_VERSION matches the Ruby version in .ruby-version
ARG RUBY_VERSION=3.4.1
FROM docker.io/library/ruby:$RUBY_VERSION-slim AS base

RUN apt-get update -qq
RUN apt-get install --no-install-recommends -y curl
RUN apt-get install --no-install-recommends -y libjemalloc2
RUN apt-get install --no-install-recommends -y libvips
RUN apt-get install --no-install-recommends -y libpq-dev
RUN rm -rf /var/lib/apt/lists /var/cache/apt/archives

CMD ["echo", "Whalecome!"]

I have split the RUN instruction into multiple lines, which obviously makes them more human-readable. But how will it affect the size of the image? Let’s build the image and check it out.


➜ time docker build -t no-minimize-layers --no-cache -f no-minimize-layers.dockerfile .
0.31s user 0.28s system 2% cpu 28.577 total

It took 28 seconds to build the image, while to build the original version with minimized layers takes only 19 seconds (almost 33% faster).


➜ time docker build -t original --no-cache -f original.dockerfile .
0.25s user 0.28s system 2% cpu 19.909 total

Let’s check the size of the images.


➜ docker images --filter "reference=*original*" --filter "reference=*no-minimize*"
REPOSITORY           TAG       IMAGE ID       CREATED          SIZE
original             latest    f1363df79c8a   8 seconds ago    356MB
no-minimize-layers   latest    ad3945c8a8ee   43 seconds ago   379MB

The image with minimized layers is 23 MB smaller than the one with no minimized layers. This is a 6% reduction in size. While it seems like a small difference in this example, the difference will be much bigger if you split all the RUN instructions into multiple lines.

Rule #3: Install only what needed

By default, apt-get install installs the recommended packages as well as packages you asked it to install. The --no-install-recommends option tells apt-get to install only the packages that are explicitly specified and not the recommended ones.


➜ time docker build -t without-no-install-recommends --no-cache -f without-no-install-recommends.dockerfile .
0.33s user 0.30s system 2% cpu 29.786 total


➜ docker images --filter "reference=*original*" --filter "reference=*recommends*"
REPOSITORY                      TAG       IMAGE ID       CREATED          SIZE
without-no-install-recommends   latest    41e6e37f1e2b   3 minutes ago    426MB
minimize-layers                 latest    dff22c85d84c   17 minutes ago   356MB

As you can see, the image without --no-install-recommends is 70 MB bigger than the original one. This is a 16% increase in size.

What files where added?

Use dive utility to see which files were added to the image – read more about it in the end of the article.

Rule #4: Clean up after installations

The original Dockerfile includes the rm -rf /var/lib/apt/lists/* /var/cache/apt/archives command after the apt-get install command. This command removes the package lists and archives that are no longer needed after the installation. Let’s see how it affects the image size, to achieve that, I will create a new Dockerfile without the cleaning command.


RUN apt-get update -qq && \
    apt-get install --no-install-recommends -y curl libjemalloc2 libvips libpq-dev

Building the images takes almost the same time as the original one, which makes sense.


➜ time docker build -t without-cleaning --no-cache -f without-cleaning.dockerfile .
0.28s user 0.30s system 2% cpu 21.658 total

Let’s check the size of the images.


➜ docker images --filter "reference=*original*" --filter "reference=*cleaning*"
REPOSITORY         TAG       IMAGE ID       CREATED          SIZE
without-cleaning   latest    52884fe50773   2 minutes ago    375MB
original           latest    f1363df79c8a   16 minutes ago   356MB

The image without cleaning is 19 MB bigger than the one with cleaning, this is a 5% increase in size.

The worst scenario

What if all four optimizations mentioned above are not applied? Let’s create a new Dockerfile without any optimizations and build the image.


# syntax=docker/dockerfile:1
# check=error=true

ARG RUBY_VERSION=3.4.1
FROM docker.io/library/ruby:$RUBY_VERSION AS base

RUN apt-get update -qq
RUN apt-get install -y curl
RUN apt-get install -y libjemalloc2
RUN apt-get install -y libvips
RUN apt-get install -y libpq-dev

CMD ["echo", "Whalecome!"]


➜ time docker build -t without-optimizations --no-cache -f without-optimizations.dockerfile .
0.46s user 0.45s system 1% cpu 1:02.21 total

Wow, it took more than a minute to build the image.


➜ docker images --filter "reference=*original*" --filter "reference=*without-optimizations*"
REPOSITORY              TAG       IMAGE ID       CREATED         SIZE
without-optimizations   latest    45671929c8e4   2 minutes ago   1.07GB
original                latest    f1363df79c8a   27 hours ago    356MB

The image without optimizations is 714 MB bigger than the original one, this is a 200% increase in size. This clearly shows how important it is to optimize the Dockerfile, larger images take more time to build and consume more disk space.

Always use .dockerignore

The .dockerignore file is similar to the .gitignore file used by Git. It is used to exclude files and directories from the context of the build. The context is the set of files and directories that are sent to the Docker daemon when building an image. The context is sent to the Docker daemon as a tarball, so it is important to keep it as small as possible.

If, for any reason, you don’t have the .dockerignore file in your project, you can create it manually. I suggest you use the official Rails .dockerignore file template as a starting point. Below is an example of what it may look like.


# See https://docs.docker.com/engine/reference/builder/#dockerignore-file for more about ignoring files.

# Ignore git directory.
/.git/
/.gitignore

# Ignore bundler config.
/.bundle

# Ignore all environment files.
/.env*

# Ignore all default key files.
/config/master.key
/config/credentials/*.key

# Ignore all logfiles and tempfiles.
/log/*
/tmp/*
!/log/.keep
!/tmp/.keep

# Ignore pidfiles, but keep the directory.
/tmp/pids/*
!/tmp/pids/.keep

# Ignore storage (uploaded files in development and any SQLite databases).
/storage/*
!/storage/.keep
/tmp/storage/*
!/tmp/storage/.keep

# Ignore assets.
/node_modules/
/app/assets/builds/*
!/app/assets/builds/.keep
/public/assets

# Ignore CI service files.
/.github

# Ignore development files
/.devcontainer

# Ignore Docker-related files
/.dockerignore
/Dockerfile*

Improving security

Having a .dockerfile file in the project not only allows excluding unnecessary files and directories (e.g., GitHub workflows from the .github folder or JavaScript dependencies from the node_modules) from the context. It also helps to avoid accidentally adding sensitive information to the image. For example, the .env file that contains the environment variables or the master.key file that is used to decrypt the credentials.

Use Dive

All the optimizations mentioned above may seem obvious when explained. What to do if you already have a massive image, and you don’t know where to start?

My favorite and most useful tool is Dive. Dive is a TUI tool for exploring a Docker image, layer contents, and discovering ways to shrink the image size. Dive can be installed with your system package manager, or you can use its official Docker image to run it. Let’s use the image from our worst scenario.


docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations

Dive Docker layers inspect tool

In the screenshot above, you can see the inspection of our the most non-optimal image. Dive shows the size of each layer, the total size of the image, and the files that were changed (added, modified, or deleted) in each layer. For me, this is the most useful feature of Dive. By listing the files in the right panel, you can easily identify the files that are not needed and remove commands that add them to the image.

One thing that I truly love about Dive is that, besides having a terminal UI, it also can provide a CI-friendly output, which can be effective in a local development too. To use it, run Dive with the CI environment variable set to true, the output of the command is in the screenshot below.


docker run -e CI=true --rm -it -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive:latest without-optimizations

Dive CI-friendly output

My personal preference is to use Dive on a scheduled basis, for example, once a week, to ensure your images are still in a good shape. In the upcoming articles, I will cover automated workflows I use to check my Dockerfile, including Dive and Hadolint.

Don’t squash layers

One approach to minimizing image size that I’ve seen is to try to squash the layers. The idea was to combine several layers into a single layer to reduce the image size. Docker had an experimental option --squash, besides this, there were third-party tools like docker-squash.

While this approach worked in the past, currently it is deprecated and not recommended to use. Squashing layers destroyed Docker’s fundamental feature of layer caching. Apart from that, while using --squash you could unintentionally include sensitive or temporary files from earlier layers in the final image. This is an all-or-nothing approach that lacks fine-grained control.

Instead of squashing layers, it is recommended to use multi-stage builds. Rails Dockerfile already uses multi-stage builds, I will explain how it works in the next article.

Conclusions

Optimizing Docker images, just like any other optimization, cannot be done once and forgotten. It is an ongoing process that requires regular checks and improvements. I tried to cover the basics, but they are critical to know and understand. In the next articles, I will cover more advanced techniques and tools that can help to make your Docker builds faster and more efficient.

Use Docker to template local database

Mon, 28 Oct 2024 00:00:00 +0400

How often do you reset your local development database? Depending on the task I am working on, I can do this even ten times a day. The reasons can be different. You or your teammate pushed an irreversible migration, which is of course not the best practice, but happens in the real life. Or you simply corrupted the data while implementing some new functionality.

TL;DR

Resetting a local development database is a common task that can take a lot of time when the database dump is large. When you need to reset your local development database, you can use Docker to template it. This will save you a lot of time when your database dump is large.

The repository with the scripts is available here.

The Problem

When your project DB size is 100Mb, it is not a problem to run psql -d project_development < project_development.sql to restore the database. But what if your project database dump is 50 GB or 100 GB? This is a common size of the database for the project that does have some real clients.

On my Mac M1 Pro, it usually takes about 30 minutes to restore a 50GB dump from the SQL data file. Resetting such a database two times a day can cost you your lunchtime. Sounds so-so.


➜  backend git:(invoices) ✗ time psql -d safari_development_1 -f ~/Downloads/safari_development.sql

psql -d safari_development -f ~/Downloads/safari_development.sql  38.48s user 121.23s system 9% cpu 27:49.06 total

Having the dump in the binary format will make it significantly smaller (8 GB instead of 50), but still, it will take a lot of time to restore it.


➜  backend git:(master) time pg_restore -d safari_development ~/Downloads/safari_development.dump

pg_restore -d safari_development ~/Downloads/safari_development.dump  180.61s user 75.97s system 13% cpu 30:39.12 total

How to speed things up?

General Idea

The general idea is elementary – somehow avoid restoring the database dump.

A similar approach works in the database replication. When your master database goes down for whatever reason, you can immediately switch to the slave database, which will become the master. You don’t need to wait while you will restore the dump from the backup.

How can we avoid restoring dump when working locally? The idea is to have a template of the database somewhere and simply copy this template instead of restoring the dump with psql or pg_restore.

PostgreSQL Templates

PostgreSQL has a built-in template system. These templates allow users to replicate the structure, schema, and any data stored in them into newly created databases. By default, PostgreSQL provides two templates: template0 and template1. This feature helps standardize new databases and streamline the creation process across multiple instances. However, since during the initialization of the database all the objects from the template are reinitialized again, it still takes quite a lot of time to run.


    ➜  backend git:(master) time createdb -T safari_development_template safari_development
    createdb -T safari_development_template safari_development  0.00s user 0.01s system 0% cpu 17:34.90 total

What does it mean with PostgreSQL? This means we should have a full copy of our PostgreSQL cluster on the disk and copy it every time we want to “restore” the database. With PostgreSQL (or any else database except the SQLite) that is installed on directly your host machine, this can be a rather tricky task. You will have to worry about management of PostgreSQL config files, environment variables and tons of other stuff. Believe me, this won’t make you development efficient.

This is where Docker comes in place. My idea was to have two versions of the database – the template and the current working version, and to have an ability to quickly copy the template to the current version.

Implementation

Before going into the detail, I want to quickly walk through the main Docker concepts that I used in this implementation. The first one is the Docker image. The image is a read-only blueprint with instructions for creating a Docker container. The second one is the Docker container. The container is a runnable instance of an image. Containers and images are managed with docker container and docker image commands accordingly. The third one is the Docker volume. The volume is a persistent data storage mechanism that allows data to exist beyond the lifecycle of a container.

Docker Volumes 101

A key feature of a Docker container is its temporary nature. When a container is deleted, any changes made to its file system are lost. To address this, Docker uses volumes. The concept is to store data on the host machine’s file system rather than within the container itself, ensuring it persists beyond the container’s lifecycle.

Dealing with a Docker volume is straightforward. Once the volume is created, it can be attached to the container. When the container is deleted, the volume is still there. You can attach the volume to another container and continue working with the data. Volumes are managed with the docker volume command.

Lets take a look the small script below.


#!/bin/bash

set -e

# Create a volume
docker volume create safari-development-template

# Start a container with the PostgreSQL database and attach the volume
docker run --name safari-development-template \
  -p 5432:5432 \
  -e POSTGRES_USER=igor \
  -e POSTGRES_DB=safari_development \
  -e POSTGRES_HOST_AUTH_METHOD=trust \
  -v safari-development-template:/var/lib/postgresql/data \
  -d postgres:17

What does it do? It creates a volume with the name safari-development-template and starts a container with the PostgreSQL database. The container is named safari-development-template and exposes the port 5432. The database name is safari_development and the user is igor. The volume safari-development-template is attached to the container.

Once the container is up, I can restore the database dump into it.


psql -d safari_development \
  -h localhost \
  -p 5432 < safari_development.sql

After about 30 minutes, the database has been restored. With Docker Desktop, I can see the volume with its size.

Docker Volumes Listing

The setup we have now is pretty standard. Our database is running in the container and the data is stored on the host machine. Such a setup allows us to do local development. Unfortunately, from the time perspective, it is not anyhow different the restoring the database dump directly on the host machine.

Now let’s move to the interesting part. Firstly, we need to create another volume that will be used for the working database. This can be done similar to the template volume creation.


docker volume create safari-development

So now we have two volumes: safari-development-template and safari-development. The first one has the data and the second one is empty. The idea is to copy the data from the first volume to the second one. Docker doesn’t provide a direct way to copy the data between the volumes, but the data can be copied between the volumes that are attached to the container. With this idea in mind I decided to use the smallest possible Docker image that has the cp command.

The busybox image is the best choice for this. It is only 4 MB in size and has many common UNIX utilities. To copy the data between the volumes, I started a container with the busybox image and attached both volumes to it to run the cp command.


docker container run --rm -it \
    -v safari-development-template:/from \
    -v safari-development:/to \
    busybox sh -c "cd /from ; cp -av . /to"

BusyBox

BusyBox was created by Bruce Perens in 1995 to address the need for a compact, efficient tool set for embedded systems running Linux. At the time, most Unix utilities were too large and complex for the limited resources of embedded devices. Perens designed BusyBox to combine essential Unix tools into a single, space-saving binary, allowing developers to run key commands in environments with minimal memory and storage.

The BusyBox Docker image is a streamlined Linux environment optimized for lightweight, containerized applications, testing, and quick tasks where minimalism is essential. This design allows BusyBox to deliver essential commands (like ls, cp, and ping) in a fraction of the space required by standard Linux distributions, making the Docker image often just a 5 Mb in size.

Once the image is downloaded, it takes about 40 seconds to copy the data between the volumes. The time is significantly less than the time it takes to restore the database dump. The data is copied, and we can start the container with the working database with the command below.


docker run --name safari-development \
  -p 5432:5432 \
  -e POSTGRES_USER=igor \
  -e POSTGRES_DB=safari_development \
  -e POSTGRES_HOST_AUTH_METHOD=trust \
  -v safari-development:/var/lib/postgresql/data \
  -d postgres:17

Now I can connect to the database and start working on the feature. When I need to reset the database, I can simply stop the container and copy the data from the template volume to the working volume again within less than a minute. This approach saves me a lot of time almost every day.

To make the process easier and more automated, I created a couple of scripts that can be used to create the template and to switch between the volumes. The repository with the scripts is available here

Usage

To create a template database use docker-db-create-template.sh, I usually put to the bin directory of the Rails project. The script that accepts two required parameters:

project_name, which is safari in our case
file_path, path to the database dump (currently in SQL format)


➜  backend git:(master) ✗ ./bin/docker-db-create-template.sh safari ~/Downloads/safari_development.sql
Stopping container safari-development-template                  done
Deleting container safari-development-template                  done
Removing existing volume safari-development-template            done
Creating new volume safari-development-template                 done
Starting container safari-development-template                  done
	Loading /Users/igor/Downloads/safari_development.sql...
into safari_development                                         done

Database safari_development is running on port 5432

What to do next:
1. Run migrations
2. Start Rails server
3. Change the data the way you want it to be in the template
4. Stop Rails server
5. Stop the database container with the command: docker stop safari-development-template
6. Run ./bin/docker-db-use-template.sh safari to use the template
Elapsed time: 1542 seconds

Now you can connect to your database on the port 5432. Do whatever preparations in the template you need. Usually this can include creating yourself a user or any other data modifications that you will need later.

When you are done with, stop your container with docker stop safari-development-template command.

It is time to use your template.


➜  backend git:(master) ./bin/docker-db-use-template.sh safari
Stopping container safari-development                             done
Deleting container safari-development                             done
Removing existing volume safari-development                       done
Creating new volume safari-development                            done
Copying data from safari-development-template                     done
Starting container safari-development                             done

Database safari_development is running on port 5432
Elapsed time: 46 seconds

Only 46 seconds and are ready to go. Start the Rails app again and work on your feature. Each time you will need to reset the database to the template simply run ./bin/docker-db-use-template.sh safari again.

Conclusions

There are two main takeaways from this post. The first is that you should try to be as effective as possible. When I see that some task takes a lot of time, I try to find a way to speed it up. It is true for my work as developer, CTO, and even true for my personal life. Time is the most valuable resource that we have.

The second is that creating a tooling around your daily tasks can save you a lot of time. I have many scripts that I use every day. They are not perfect, but they do the job. I am excited to share them with you. For any clarifications or suggestions, feel free to reach me out on X.

Rails Thruster 101

Mon, 23 Sep 2024 00:00:00 +0400

While we are waiting for the Rails World 2024 conference to start and Kamal 2 to be released, I decided to make some preparations for the upcoming changes in the Rails ecosystem.

In March 2024 Basecamp team released Thruster a small, Go-based proxy server for Rails. While the original idea of Thruster was to provide an ability to build production-ready Rails applications from a single container for the ONCE project, it will fit perfectly to the Kamal ecosystem.

Isn’t it a redundancy?

Wait? Another proxy server? Why do we need it? Allow me to explain.

It doesn’t matter whether we use Traefik with Kamal v1 or kamal-proxy with Kamal v2, inside the container we still run Puma (or any other Ruby application server) that serves requests to the application. Besides this, Puma is also responsible to serving application assets – images, stylesheets, JavaScript files, etc. – to the clients. Before Kamal came into the scene, we usually had Nginx in our infrastructure schema. Nginx is a classic web server that can serve static files efficiently. Unfortunately, it is not adapted to the container-based setups as you need to manage its configuration via a config file. However, without Nginx, Puma is not the best choice to serve static files.

This is where Thruster comes into play. It wraps the Puma instance and efficiently serves static files with X-Sendfile acceleration, while Puma is responsible for the dynamic content.

Thruster also provides GZip compression which was available in Traefik via middleware, but won’t exist in kamal-proxy. GZip compression plays a crucial role in optimizing web performance by significantly reducing the size of files transmitted between a server and a client. By compressing assets like HTML, CSS, and JavaScript, GZIP decreases bandwidth usage and accelerates the loading times of web pages, providing users with a faster, more seamless browsing experience. This not only enhances user satisfaction but also improves search engine rankings, as faster websites tend to rank higher in search results. Additionally, reducing the size of data transfers lightens the load on servers, allowing them to handle more requests efficiently and lowering hosting costs.

A reasonable question would be “Why I cannot do a GZIP compression in Rails?”. Technically, you can with Rack::Deflater. But since Thruster is already responsible for serving public assets, it can also efficiently handle compression.

Besides a compression, Thruster also provides a basic HTTP caching of public assets and HTTP/2 support.

With Thruster your Rails application can be treated as a black box, which can serve any kind of requests efficiently.

How to use?

Thruster is straightforward to use if you’re already using Puma.

First, you need to add Thruster to your Gemfile:


# Gemfile

gem 'thruster'

Run bundle install and you are ready to go. Since Thruster is written in Go, platform specific binary will be downloaded and installed with the gem.

I always create binstubs to have all the necessary commands in one place:


$ bundle binstubs thruster

By default, Thruster will listen on port 80, while Puma will stay on port 3000. Knowing this we should update our application Dockerfile accordingly. I assume here that your application is already dockerized. I replaced the port that is getting exposed from 3000 to 80 and added ./bin/thrust to the default command.


# Dockerfile

# Entrypoint prepares the database.
ENTRYPOINT ["/rails/bin/docker-entrypoint"]

# Start server via Thruster by default, this can be overwritten at runtime
EXPOSE 80
CMD ["./bin/thrust", "./bin/rails", "server"]

The last change is to update ./bin/docker-entrypoint script. I always try to keep it as close to the original Rails template as possible. Below is the final version of the script.


#!/bin/bash -e

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

exec "${@}"

That is all! Thanks to the Traefik container-based configuration, it will read the exposed port from the container and route the traffic accordingly after you will deploy the changes.

After deploy will be finished, you can log in to the container and check if Thruster is running:


rails@docker:~$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
rails          1  0.0  0.3 1232848 13124 ?       Ssl  09:26   0:06 /usr/local/bundle/ruby/3.3.0/gems/thruster-0.1.8-x86_64-linux/exe/x86_64-linux/thrust ./bin/rails server

Summary

Since there are no visible cons of using Thruster in your Rails application, I highly recommend using it. It can improve the performance of your application and reduce the load on the server. It is also a good idea to use it as a preparation for the upcoming Kamal 2 release.

Odd Ruby return values

Fri, 30 Aug 2024 00:00:00 +0400

Earlier this week I published a tweet that made some buzz in the community. To be honest, I didn’t expect that so many people would be interested in this topic. About 29000 views and 1600 votes is quite an impressive result for 9 lines of code.

The tweet was about the following code snippet:

class Klass
  def self.square(value)
    if value > 0
      value * value
    end
  end
end

puts Klass.square(0)

The question was: what is the result of the Klass.square(0) method call?

TL;DR

The result of the Klass.square(0) method call is nil. From 1600 votes, about 1500 people gave the correct answer.

Explanation

Every expression in Ruby has a value.

A conditional statement in Ruby is an expression that returns nil if the conditional is false. Ruby methods return the last expression in the method body.

So, in the code snippet above, 0 is not greater than 0, so the if statement returns nil. The Klass.square method returns the result of the if statement (because it is the last expression), which is nil.

Elementary, right? Yes, but since there were about 100 people who gave the wrong answer (0), even such simple things can be tricky and odd.

More odd examples

In the comments to the tweet, Lucian Ghinda pointed to a similar, odd example originally found by Rob Lacey.

It turns out that local variable assignment in Ruby assigns nil even if the right part of the expression is not defined.

irb(main):001> local_var = undefined_var
(irb):1:in `<main>': undefined local variable or method `undefined_var' for main:Object (NameError)

local_var = undefined_var
            ^^^^^^^^^^^^^
  from /Users/igor/.rbenv/versions/3.2.3/lib/ruby/gems/3.2.0/gems/irb-1.13.2/exe/irb:9:in `<top (required)>'
  from /Users/igor/.rbenv/versions/3.2.3/bin/irb:25:in `load'
  from /Users/igor/.rbenv/versions/3.2.3/bin/irb:25:in `<main>'
irb(main):002> local_var
=> nil

To be honest, I didn’t know about this behavior before.

Why do I ask this in interviews?

In my original post, I mentioned that I ask this question in interviews. This triggered a discussion about whether it is a good idea to ask such questions in interviews.

Yes, I believe that at the beginning of your career, it is crucial to understand how the language you are working with works. It is important to know all the nuances and dive as deep as you can. Even if the candidate doesn’t know the answer, which is usual and normal in entry-level positions, he can always demonstrate his thinking curve which, start discussion and try to explain the potential behavior. Focusing on how a candidate thinks and approaches problems can reveal a lot about their potential and willingness to learn, which is especially important early in their careers.

Conclusions

Today you learned, or, I hope, you remembered, that every expression in Ruby has a value. Conditional statements in Ruby are expressions that return nil if the conditional is false.

Redirect and return in Rails controllers

Fri, 23 Aug 2024 00:00:00 +0400

Premature returning from a controller action is a common idiom in Rails applications. I asked my followers in Twitter about whether they know or know how to do this correctly, and I am glad to see that most of them gave the correct answer. Let’s dive into the details.

Before we start, I suggest you to take a look at the post, I mentioned above, to see the answers and to try to solve the problem by yourself. If, for some reason, you can’t or don’t want to do this, I created a screenshot for you.

Original Twitter post with answers

Most of those who votes made the right choice. Correct answers were options 1 and 2. I usually use the first one, but the second option was also correct.

To understand why the first and the second options are correct, I recommend you to read the table of operator precedence in Ruby.

&& operator in options 2 and 3

Using && in options 2 and 3 is a bit tricky.

redirect_to(sign_in_path) && return

In the expression above, && operator get the result of redirect_to(sign_in_path) as the left operand and return as the right operand. This expression will work correct.

redirect_to sign_in_path && return

However, without explicit brackets, && get the result of sign_in_path as the left operand and return as the right operand. The value of the return keyword is nil, so the expression above can be rewritten as:

redirect_to sign_in_path && nil

Whatever && nil will return nil, and redirect_to will be called with nil as an argument, which finally will raise an error.

ActionController::ActionControllerError in TimeOffsController#new
Cannot redirect to nil!

Option 4

There was no way to vote for the fourth option directly, but there were a few who said that all options were correct.

def show
  redirect_to sign_in_path unless current_user

  @time_off = current_user.time_offs.find(params[:id])

  render @time_off
end

In Rails, redirect_to does only sets correct response headers and status code, but it doesn’t stop the execution of the action. In the example above, if current_user is nil, you will face DoubleRenderError.

AbstractController::DoubleRenderError in TimeOffsController#new
Render and/or redirect were called multiple times in this action.

UPD. Difference between `&&` and `and`

Above in the post, I posted the link to the table of operator precedence in Ruby. Both && and and are logical operators in Ruby, but they have different precedence, && has higher precedence than and. This difference in precedence can lead to unexpected behavior when they are used in complex expressions.

# Using &&
a = true && false
b = false && true

puts a # => false
puts b # => false

# Using and
c = true and false
d = false and true

puts c # => true
puts d # => false

Pretty interesting, right?

In the first case &&, the assignment happens after evaluating the expression, so a and b are both assigned the result of the logical operation false.

In the second case and, the assignment happens before the logical operation because and has lower precedence than =. So c is first assigned true, and then the logical and operation is evaluated, which does not affect the assignment.

Let’s take a look at the another example.

# Using &&
a = b = false && true
puts a # => false
puts b # => false

# Using and
c = d = false and true
puts c # => false
puts d # => false

With &&, both a and b are assigned the result of false && true, which is false. With and, d = false is evaluated first (due to and’s lower precedence), and then c = d is assigned.

You should be careful when using and and && in complex expressions. It is better to use && for logical operations, while and can be used to control flow.

Conclusions

Despite the fact my post was about Ruby operator precedence, there were people who suggested that it is better to use before_action for such kind of checks. I agree. I will try to be more explicit in my future posts and will provide more context.

Nevertheless, I hope you learned something new. Stay tuned!

Upgrading Rails application from 7.1 to 7.2

Sun, 11 Aug 2024 00:00:00 +0400

On August 9th, Rails 7.2 was released, bringing a host of new features and improvements to the framework. Ten months ago, I demonstrated how to upgrade a Rails application from 7.0 to 7.1, which was well-received by the community. Today, I will take you through the process of upgrading OneTribe from Rails 7.1 to 7.2. This upgrade not only ensures compatibility with the latest Rails enhancements but also allows me to better understand new Rails functionalities and performance optimizations. Let’s dive into the upgrade process and explore what Rails 7.2 has to offer.

Prerequisites

OneTribe runs Ruby 3.3.4 and Rails 7.1.3, which is good because Rails 7.2 requires Ruby 3.1.0 or newer. Nothing changed in code hosting and deployment, we still use GitHub and GitHub Actions with Kamal.

Dependencies Update

The first you do to upgrade Rails is to change the version in the Gemfile.

# Gemfile
# ...
gem "rails", "~> 7.2.0"
# ...

Than you do bundle update rails and either you will be see that everything is fine or you will see that something is wrong. In my case, I got an error that pg_party does not support Rails 7.2 yet. I checked the gem’s repository and saw that there was already a PR with support for Rails 7.2, but it has not yet been merged. I decided to use the code from the PR.

# Gemfile
# ...
gem "pg_party", github: "marcoroth/pg_party", branch: "rails-7.2"
# ...
gem "rails", "~> 7.2.0"
# ...

After I fixed the issue, I tried to run specs with ./bin/rspec and got a strange error.

An error occurred while loading ./spec/workers/member/next_birthday_worker_spec.rb.
Failure/Error: require File.expand_path('../config/environment', __dir__)

NameError:
  undefined method `validate_find_options' for class `#<Class:ActiveRecord::Base>'
# ./config/application.rb:22:in `<top (required)>'
# ./config/environment.rb:4:in `require_relative'
# ./config/environment.rb:4:in `<top (required)>'
# ./spec/rails_helper.rb:6:in `<top (required)>'
# ./spec/workers/member/next_birthday_worker_spec.rb:3:in `<top (required)>'

I ran ./bin/rspec -b to see the backtrace and found that the error was caused by the acts_as_paranoid gem. We used very old version of the gem, so I updated it to the latest version and bundled.

I found out that I didn’t migrate the database when I fetched the latest changes from the repository. I ran ./bin/rails db:migrate and got another error.

➜  onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate
Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record.
bin/rails aborted!
NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError)

        pool.with_connection do |connection|
            ^^^^^^^^^^^^^^^^
Did you mean?  raw_connection

Tasks: TOP => db:schema:dump
(See full trace by running task with --trace)

To debug this I again used --backtrace option.

➜  onetribe git:(rails-7-2) ✗ ./bin/rails db:migrate --backtrace
Rodauth::Rails.authenticated has been deprecated in favor of Rodauth::Rails.authenticate, which additionally requires existence of the account record.
bin/rails aborted!
NoMethodError: undefined method `with_connection' for an instance of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter (NoMethodError)

        pool.with_connection do |connection|
            ^^^^^^^^^^^^^^^^
Did you mean?  raw_connection
/Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/activerecord-7.2.0/lib/active_record/schema_dumper.rb:45:in `dump'
/Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:18:in `block (4 levels) in <main>'
/Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `open'
/Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/hairtrigger-1.0.0/lib/tasks/hair_trigger.rake:17:in `block (3 levels) in <main>'

Backtrace helps quickly identify the issue. In my case it was the hairtrigger gem that was outdated and not compatible with Rails 7.2.

Finally, I was able to migrate and run specs successfully with ./bin/rspec.

Third-party Deprecations

During RSpec run I saw a couple of deprecation warnings and decided to fix them before going further.

DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated
and will be removed in Rails 8.0. Use #lease_connection instead.

I don’t use connection directly in the code, so the message was caused by some gem. The problem was that I had no idea which gem caused the warning. How would you handle this? I found out that starting from a Rails 7.1 there is a Rails.application.deprecators API, which can be extremely useful in this case.

I updated my config/application.rb file to include the following code:

# config/application.rb

module OneTribe
  class Application < Rails::Application
    # ...
    deprecators.debug = true if ENV["DEPRECATION_DEBUG"]
  end
end

Then I ran the specs with DEPRECATION_DEBUG=true ./bin/rspec and saw the following output:

DEPRECATION WARNING: ActiveRecord::ConnectionAdapters::ConnectionPool#connection is deprecated
and will be removed in Rails 8.0. Use #lease_connection instead.
 (called from load at ./bin/rspec:27)
/Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:15:in `block in all_connections'
  /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `map'
  /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:13:in `all_connections'
  /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all/adapters/active_record.rb:36:in `begin_transaction'
  /Users/igor/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/gems/test-prof-1.3.3.1/lib/test_prof/before_all.rb:24:in `block in begin_transaction'

Now everything was clear. The warning was caused by the test-prof gem. I decided to ignore it for now and continue with the upgrade.

Rails Deprecations

Another deprecation warning I saw was:

➜  onetribe git:(rails-7-2) ✗ ./bin/rspec

DEPRECATION WARNING: Defining enums with keyword arguments is deprecated and will be removed
in Rails 8.0. Positional arguments should be used instead:

enum :role, {:employee=>"employee", :manager=>"manager", :administrator=>"administrator"}
 (called from <class:Member> at /Users/igor/workspace/onetribe/app/models/member.rb:14)

In mid-February 2024, there was a PR that deprecated defining enums with keyword arguments. Before it was possible to define enums like this:

# app/models/time_off/slot.rb


class TimeOff::Slot < ApplicationRecord
  # ...

  enum allocation_type: { general: 0, extra: 1, auto: 2 }, _prefix: :allocation_type
end

With this change you should define enums like this:

# app/models/time_off/slot.rb

class TimeOff::Slot < ApplicationRecord
  # ...

  enum :allocation_type, { general: 0, extra: 1, auto: 2 }, prefix: :allocation_type
end

This new syntax eliminates the need to prefix options with an underscore.

For some reason, this change wasn’t mentioned in the Rails 7.2 release notes, but it’s good to know about it.

Application Configuration Update

Rails has a special task rails app:update that can help you to update application configuration in an interactive mode. I use VS Code for development and wanted to use its merge tool, so as in the previous update, I specified THOR_MERGE constant before running the command THOR_MERGE="code --wait" ./bin/rails app:update and used merge tool (m option) to track changes over files.

During the update I found only one notable configration change.

Annotation of views with filesnames is now anabled by default in development. This setting is handled by config.action_view.annotate_rendered_view_with_filenames = true in config/environments/development.rb.

<h3 class="mb-4 text-lg font-medium text-center">
  Team Schedule
</h3>

<!-- BEGIN app/views/companies/time_offs/shared/_monthly_calendar.html.slim -->
<div id="monthly_calendar">
  <!-- ... -->
</div>
<!-- END app/views/companies/time_offs/shared/_monthly_calendar.html.slim -->

With this setting enabled, you will see comments like this in the HTML source of the page. I am not sure if it’s useful, but it’s good to know about it.

App Defaults

After you merge all the changes, you can run the specs again to make sure everything is fine. Now it is time to make sure that your application is ready to run with Rails default settings, applied to every new Rails 7.2 application.

This can be done in two steps. In config/initializers there should be a new file named new_framework_defaults_7_2.rb. It includes all Rails 7.2 default params commented, so you can enable them one by one and make sure that your specs are still green and your application is still working.

After after, you can change config.load_defaults in config/application.rb file to have 7.2 value and delete new_framework_defaults_7_2.rb. This will enable all options at once.

Development Container

One new feature of Rails 7.2 that deserves to be mentioned in this text is format support of Docker development containers. Yes, nobody prevented you from using dev container before Rails 7.2, but now you can generate container configuration for new apps with rails new myapp --devcontainer command. This will create a new Rails app with the .devcontainer folder that includes devcontainer.json, Dockerfile and docker-compose.yml files.

For applications that were upgrade you can use ./bin/rails devcontainer console command to generate the same files.

Conclusions

Since 7.2 is a minor release, there are not many changes and new features, however the Release Notes are rather long. I will not cover everything here, but I suggest you to read them. Maybe I will write a separate post about some of the new features.

Stay tuned!

Happy Birthday, Rails! 🎉

Sat, 03 Aug 2024 00:00:00 +0400

Fifteen years ago, in August 2009, I worked for a small network provider company. I was a junior developer, yes 15 years ago, junior devs didn’t become seniors in 3 months. We used Dolphin SmallTalk for our internal systems, and I had the task of creating a simple web application for our customers. Also in the summer, but 20 years ago in July 2004, David Heinemeier Hansson released the first version of Ruby on Rails. I watched this video, and my life has changed.

Rails was a game-changer for me. I’ve been working with PHP and Java before, but Rails was different. It was a framework that was built with developers in mind. It was a framework that was built to make developers happy. And it did. It made me happy.

Let me explain, fifteen years back, web development was a bit different. We didn’t have all these fancy tools and libraries that we have today. We didn’t have Webpacker, we didn’t have Yarn, we didn’t have Tailwind CSS. Everything was overcomplicated. With Java, you had to start by reading a 600-page book, understanding the concept of Servlets, JSP, and J2EE, and god knows what else J. PHP was everywhere, but it was a mess. Every developer started their path by writing his authentication solution. You had to write your own ORM, you had to write your own MVC framework, and you had to write almost everything from scratch.

You can say, “What about Django and ASP.NET, dude?”. Yes, they were there. But ASP.NET was a Microsoft thing, and I was a Linux guy. Without .NET Core it was impossible to run ASP.NET on Linux. And, yes, there was Mono, and as far as I remember, it was possible to run ASP.NET on Linux, but the phrase “OpenSource sponsored by Microsoft” sounded like a joke those days.

Django was a good thing to use for web dev. Compared to everything else it was a breakthrough. And I tried it, but two things made me stick with Rails. First, Django is Python. After using SmallTalk, where everything is an object, Python felt like a more multi-paradigm language, which it is. The second thing is that Django does a lot of things too complicated. I remember my impressions from the routing based on regular expressions. I am not saying that it is bad, of course not. I just needed something more straightforward.

And Rails was it. It was more straightforward because it was built on the principle of “Convention over Configuration”. It was more straightforward because it was built on the principle of “Don’t Repeat Yourself”. It was more straightforward because it was built on the principle of “You Ain’t Gonna Need It”. It was more straightforward because it was built on the principle of “Keep It Simple, Stupid”.

Rails meets its 20th birthday in good shape. Yes, like every software, it has its problems, it becomes more and less popular from time to time. It has fans and haters. But it is still here. It is still my tool to make money and to make me happy. And I am grateful for that.

Happy Birthday, Rails! 🎉

Ruby & Beyond

Where is the software development industry going?

Kamal 2 – Get out of the cloud

Kamal cheat sheet

Rails Dockerfile Best Practices – Part 1: Image Slimming

Why to optimize the image size?

Faster builds & deployments

Reduced storage costs & network bandwidth usage

Improved performance & security

Inspecting Docker images

Optimize packages installations

Rule #1: Use minimal base images

Rule #2: Minimize layers

Rule #3: Install only what needed

Rule #4: Clean up after installations

The worst scenario

Always use .dockerignore

Use Dive

Don’t squash layers

Conclusions

Use Docker to template local database

TL;DR

The Problem

General Idea

Implementation

Usage

Conclusions

Rails Thruster 101

Isn’t it a redundancy?

How to use?

Summary

Odd Ruby return values

TL;DR

Explanation

More odd examples

Why do I ask this in interviews?

Conclusions

Redirect and return in Rails controllers

&& operator in options 2 and 3

Option 4

UPD. Difference between && and and

Conclusions

Upgrading Rails application from 7.1 to 7.2

Prerequisites

Dependencies Update

Third-party Deprecations

Rails Deprecations

Application Configuration Update

App Defaults

Development Container

Conclusions

Happy Birthday, Rails! 🎉

UPD. Difference between `&&` and `and`