DEV Community: Michel Sánchez Montells

Copy & Paste PostgreSQL Query Results into Google Sheets (No CSV Needed)

Michel Sánchez Montells — Fri, 15 Aug 2025 10:48:14 +0000

Sometimes, as developers, we need to share query results with teammates maybe to explain a bug, show app behavior, or provide visibility into some data. Often, this means copying directly from the terminal.

But here’s the catch: 😕

Pasting raw SQL output into a text editor or a spreadsheet usually ends in a chaos 😫😤😞. Everything dumped into a single cell, broken formatting, unreadable messes 🥴.

And yet, putting this data into Google Sheets is super helpful: it’s clear, searchable, and collaborative. But exporting to CSV just for that? Too much friction.

Here’s a dead-simple way to copy query results from psql and paste them cleanly into Google Sheets—no CSVs, no cleanup, no formatting pain.

🔧 How to do it (in seconds):

1. Open your terminal and start `psql`:

psql -U your_user -d your_database

2. Set output to tab-separated format (what Google Sheets understands natively):

\x off
\pset format unaligned
\pset fieldsep '\t'

3. Run your query:

SELECT id, name, email FROM users LIMIT 10;

4. Copy the result from your terminal and paste it directly into Google Sheets.

😲 Each column goes perfectly into its own cell
😄 Each row drops nicely into a separate row
😌 No cleaning, no reformatting, just pure copy/paste joy

No CSV. No cleaning. No pain.

Hope this saves you time!
If it did, give it a 💚 or share it with your team.

How to Upgrade PostgreSQL with Docker Compose and Bitbucket Pipelines (Step-by-Step Guide)

Michel Sánchez Montells — Wed, 30 Jul 2025 13:44:52 +0000

Working in a old RoR application I was asked to updgrade Postgresql from 9.5 up to the latest possible. The RoR application is deployed on premises via Docker Compose.

The postgres documentation explains and recomends:

We always recommend that all users run the latest available minor release for whatever major version is in use. https://www.postgresql.org/support/versioning/

Fortunately my current version is the last minor version for 9.5 -> 9.5.25. Then I will upgrade from 9.5 to 9.6.

Some reasonable steps for migrating in this conditions are described in:

Finally, I want to achieve my goal without ssh into the server and manual steps. I would like to achieve this setting up a manual CI pipeline|job and pushing some simple changes like renaming docker-compose volumes as the unique human intervention making this process as repeatable and as less error prompt as possible 🙏.

In this case Bitbucket-Pipeline. Any way this approach should work with some adapts on whatever CI service allows to execution of custom bash commands. (Jenkins, GitlabCi, among others).

Hopefully, after the first round of this upgrading cycle I will be able to perform the rest of the upgrades just changing numbers 🙏.

After said all my preconditions, requirements, and ambitious. Let's put the hands on the keyboard.

This is my docker-compose.yml simplified for the sake of simplicity. Only services and needed details for my purpose are shown.

version: '2.1'  
services:  
  web:  
    image: my_ror_image
    depends_on:  
      - pg  
  pg:  
    image: postgres:9.5-alpine  
    volumes:  
      - ./tmp/db:/var/lib/postgresql/data  
    environment:  
      - POSTGRES_PASSWORD=pass  
      - POSTGRES_USER=user  
      - POSTGRES_DB=db_prod_pass  
    hostname: pg

Step 1: Adapt my docker-compose in the way that the specs involve the version.

version: '2.1'  
services:  
  web:  
    image: my_ror_image
    depends_on:  
      - pg  
  pg:  
    image: postgres:9.5-alpine  
    volumes:  
      - ./tmp/db_9.5:/var/lib/postgresql/data  
    environment:  
      - POSTGRES_PASSWORD=pass  
      - POSTGRES_USER=user  
      - POSTGRES_DB=db_prod_pass  
    hostname: pg

Here, the name of host directory mapped to the container directory is using the version. It will allow me to conserve both versions in the automatic upgrade process in order to being able to rollback in case of failure.

Step 2: Deploy the app with the current approach

Here before doing any upgrade we will re-deploy our app using different folder for storing/sharing data with/between our host and the pg container.

ssh to your server, create the directory with the name including the version, and copy all content of the previous pg-data directory.

mkdir <app-dir>/tmp/db_9.5
cp <app-dir>/tmp/db <app-dir>/tmp/db_9.5
redeploy the last version including addapted docker-compose

The new deployed app will take data from the directory that includes the version on the name.

This is step is manual but will never be repated, it is part of the
preparation.

Step 3: Create a docker-compose file for the upgrade process

version: '2.1'
services:
  new_pg:
    image: postgres:${VERSION_TO}-alpine
    volumes:
      - ./tmp/db_${VERSION_TO}:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=password
      - POSTGRES_USER=user
      - POSTGRES_DB=db_labs

  old_pg:
    image: postgres:${VERSION_FROM}-alpine
    volumes:
      - ./tmp/db_${VERSION_FROM}:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=password
      - POSTGRES_USER=user
      - POSTGRES_DB=db_labs

Here we are for convinient using environment variables for set the involved versions. This docker compose will start two containers with the both FROM and TO versions of postgres. We will use them for dumping loading 😉

Step 4: The Bitbucket Pipeline

upgrade_postgres:
  - variables:
      - name: DeployCode
        default: staging
        allowed-values:
          - production
          - staging
          - labs
      - name: UP_PG_FROM
        default: '9.6'
        allowed-values:
          - '9.6'
          - '10'
          - '11'
          - '12'
          - '13'
          - '14'
      - name: UP_PG_TO
        default: '10'
        allowed-values:
          - '10'
          - '11'
          - '12'
          - '13'
          - '14'
          - '15'
  - step:
      name: 'upgrade-postgres'
      script:
        - *prepare_ssh
        - scp -o StrictHostKeyChecking=no ./docker-compose-${DeployCode}.yml ${SSH_SERVER_ADDRESS}:/web-app/
        - scp -o StrictHostKeyChecking=no ./docker-compose-pg-upgrade.yml ${SSH_SERVER_ADDRESS}:/web-app/
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-${DeployCode}.yml down --remove-orphans"
        - ssh_connect_to_deployment_server "cd /web-app && VERSION_FROM=$UP_PG_FROM VERSION_TO=$UP_PG_TO docker-compose -f docker-compose-pg-upgrade.yml up -d"
        - ssh_connect_to_deployment_server "mkdir -p /web-app/tmp/db_load_$UP_PG_TO"
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-pg-upgrade.yml exec -T old_pg mkdir db_dump_$UP_PG_FROM"
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-pg-upgrade.yml exec -T new_pg mkdir /db_load_$UP_PG_TO"
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-pg-upgrade.yml exec -T old_pg pg_dumpall -U user -f /db_dump_$UP_PG_FROM/dump.sql"
        - ssh_connect_to_deployment_server "docker cp wm-web-app-${DeployCode}_old_pg_1:/db_dump_$UP_PG_FROM/dump.sql /web-app/tmp/db_load_$UP_PG_TO/dump.sql"
        - ssh_connect_to_deployment_server "docker cp /web-app/tmp/db_load_$UP_PG_TO/dump.sql wm-web-app-${DeployCode}_new_pg_1:/db_load_$UP_PG_TO/dump.sql"
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-pg-upgrade.yml exec -T new_pg psql -U user -d postgres -f /db_load_$UP_PG_TO/dump.sql"
        - ssh_connect_to_deployment_server "cd /web-app && docker-compose -f docker-compose-pg-upgrade.yml down --remove-orphans"

This bitbucket pipeline stop the our online application. Start two postgres container with both versions. Dump the FROM version and load it in the TO version, helping with docker cp feature and bitbucket pipeline variables feature.

ℹ️ Just make sure the VERSION_FROM and VERSION_TO values match the
subfolder names in your tmp/ volume folder. That’s what keeps
everything clean and rollback-ready.

Step 5: Run this pipeline manually on bitbucket.

Step 6: Update your production docker compose and redeploy.

After a successful upgrade:

Update your production docker-compose to use the new version and its corresponding volume:
```
 volumes:
      - ./tmp/db_10:/var/lib/postgresql/data
 image: postgres:10-alpine
```
Commit this change and redeploy.

Conclusion

What started as a scary task of upgrading an old Postgres DB turned out to be a repeatable and safe process. With just a few abstractions (a second Docker Compose file and a CI job), I turned it into a hands-off operation. Next time I want to upgrade, all I’ll do is change the FROM and TO versions and hit “Run pipeline”.

💡 Automation is not just about speed — it’s about reliability and peace of mind.

Hope this helps you on your own upgrade journey! 🙌

Writing Reusable and Performant Scopes in Rails with .merge

Michel Sánchez Montells — Sat, 19 Jul 2025 10:15:07 +0000

How to combine scopes in Rails in a DRY and efficient way?

In my day-to-day work with Rails, I use scopes in almost every model. They’re the perfect tool to encapsulate filtering logic, keep code clean, and build complex queries in a readable way.

One of the most common cases:

"I want the published posts from active authors living in America, except if they write in Portuguese or English."

Nothing fancy, right?
But here’s where many of us (myself included) hit a common question:

Should I chain scopes directly? Or use .merge? Does it matter?

Spoiler: It does matter.

The setup: authors and posts

In this example, we have two classic models: Author and Post.

# app/models/author.rb
class Author < ApplicationRecord
  has_many :posts

  scope :from_america, -> { where(continent: 'America') }
  scope :excluding_languages, -> (langs) { where.not(language: langs) }
  scope :active, -> { where(active: true) }

  # Chained and reusable scope
  scope :american_active_no_pt_en, -> {
    from_america.active.excluding_languages(%w[pt en])
  }
end

# app/models/post.rb
class Post < ApplicationRecord
  belongs_to :author
  scope :published, -> { where(published: true) }
end

The requirement

Our client (or product team, or pragmatic mind) wants this:

"Give me all published posts by active authors who live in America and do not write in Portuguese or English."

And as good developers, we want this to be:

DRY
Performant
Reusable

So, we try different approaches.

First solution: DRY, but with a subquery (less performance)

scope :by_active_american_authors, -> {
  where(author_id:  Author.american_active_no_pt_en.select(:id))
}

Typical usage:

`# app/models/post.rb  
Post.published.by_active_american_authors`

Generated query:

SELECT "posts".*  
FROM "posts" 
WHERE "posts"."published" =  TRUE  
AND "posts"."author_id" IN ( SELECT "authors"."id" 
                             FROM "authors" 
                             WHERE "authors"."continent" =  'America'  
                             AND "authors"."active" =  TRUE  
                             AND "authors"."language" NOT  IN ('pt', 'en'));`

This approach is super DRY.

We reuse Author.american_active_no_pt_en without duplicating logic.
But: it uses a subquery in the WHERE IN, which can become expensive if there are many authors or if that scope includes additional joins.

Second solution: efficient, but repetitive

scope :by_active_american_authors, -> {
  joins(:author)
  .where( authors: { continent:  'America', active:  true })
  .where.not( authors: { language:  %w[pt en] }
  )
}

Typical usage:

Post.published.by_active_american_authors

Generated query:

SELECT "posts".*  
FROM "posts" 
INNER  JOIN "authors" ON "authors"."id" = "posts"."author_id" 
WHERE "authors"."continent" =  'America'  
  AND "authors"."active" =  TRUE  
  AND "authors"."language" NOT  IN ('pt', 'en') AND "posts"."published" =  TRUE;`

Here the query is very efficient: the JOIN lets the DB use indexes.
But we’re duplicating the logic already defined in Author.american_active_no_pt_en.
Every time that logic changes, we have to remember to update it in multiple places.

And we all know how those stories end.

Third solution: DRY and efficient with `.merge`

scope :by_active_american_authors, -> {
  joins(:author).merge(Author.american_active_no_pt_en)
}`

Typical usage:

Post.published.by_active_american_authors

Generated query (same as above):

SELECT "posts".*  
FROM "posts" 
INNER  JOIN "authors" ON "authors"."id" = "posts"."author_id" 
WHERE "authors"."continent" =  'America'  
  AND "authors"."active" =  TRUE  
  AND "authors"."language" NOT  IN ('pt', 'en') 
  AND "posts"."published" =  TRUE;

With .merge, we get the best of both worlds:

✅ We reuse the scope from the Author model, keeping the code clean.
✅ We generate an optimal query, with no subqueries.

So… what does `.merge` actually do?

We’ve seen .merge gives us both efficiency and reuse.

But if you’re like me, you want to know how it works and when it can fail.

Does Rails run the scope first and then mix the results?

No. .merge doesn’t run anything separately.

Rails fuses(merge) the SQL conditions of the second scope into the first one.

It’s not that Author.american_active_no_pt_en gets executed and its results passed over.

Here’s what’s really happening:

`Post.joins(:author).merge(Author.active)`

Rails interprets this as:

“Okay, you're doing a join with authors, and you want to apply conditions from this other scope in Author. Let me mix that into one single ActiveRecord::Relation.”

The result is a single SQL query.

What exactly gets copied?

Rails takes from the second scope things like:

WHERE
JOIN
ORDER
LIMIT, OFFSET, GROUP BY (with some caveats)

And it adds them into the ActiveRecord::Relation you’re building with Post.

What if I try `.merge` without a `join`?

Example:

Post.merge(Author.active) # ❌`

This will raise an error.

Rails doesn’t know how to apply authors conditions in a query that only involves posts.

The right way is:

Post.joins(:author).merge(Author.active)`

Can `.merge` break things?

Yes. Here are real situations where .merge can cause trouble:

1. When the merged scope uses select

# This overrides the base model's select  
Author.select(:id, :name).merge(Author.active)`

2. When using aliases or multiple joins

Post.joins(:author, :editor).merge(Author.active) # ⚠️ Rails may get confused`

3. When the scope uses group, limit, or offset

It won’t always break, but can produce unexpected SQL or DB errors.

Best practices for `.merge`

Use .merge only when the relation is already loaded (joins, includes, etc.).
Avoid select, group, limit, or offset in scopes you plan to merge.
Don’t merge scopes that don’t apply to the current base model.
Name your scopes well so they’re expressive (.visible_to_user, .eligible_for_export, etc.).

So… how should you think about `.merge`?

This is how I see it:

“Take this logic that’s already defined in another model and blend it into my current query… without breaking anything.”

And when that’s what you need, .merge is just 🔥.

Accelerate Maven Application Builds: Maximizing Efficiency with Docker Volumes for Maven Repository Sharing

Michel Sánchez Montells — Sun, 19 May 2024 20:22:30 +0000

In today's software development landscape, dockerization has become a fundamental requirement for every project. It eliminates the notorious "it works on my laptop" dilemma, promotes seamless collaboration within teams, and enables hassle-free deployment across various environments using tools like Docker Compose. Our goal is to achieve all of this while maintaining an easy-to-use and highly efficient development environment.

Now, let's dive into dockerizing a Java Maven application and explore the challenges we face. Traditionally, developers often rely on using a Maven image as the base image for their Docker setup, such as the popular Maven 3.6.0 with JDK 8 on Alpine Linux:

Then we want to dockerize a Java Maven application.

We should to be able of

build:

docker build -t my-java-app .

run:

docker run my-java-app

One of the prevalent approaches is to have a maven image as a docker base image.

FROM maven:3.6.0-jdk-8-alpine

include the pom

COPY pom.xml .

include the code

COPY src ./src

build the app

mvn package

However, this approach poses a significant drawback. Every time we execute the docker build command, Maven will re-download the project's dependencies and rebuild the application from scratch if there are any changes in the dependency list or the source code within the src directory. This process is not only inefficient but also tedious and painfully slow.

But fear not! There's a better way to handle this.

By executing the dependency downloads inside the container and leveraging the power of Docker volumes, we can share the Maven repository between the host and the container. Here's how we can achieve it:

We can do it better.

Execute the download dependencies inside the container and share with
docker volume the maven repository between host and container.

Yes, Inherit from maven

FROM maven:3.6.0-jdk-8-alpine

Copy pom and code

COPY pom.xml .
COPY src ./src

Use docker entrypoint.sh pattern

COPY docker-entrypoint.sh /docker-entrypoint.sh

Note: this file must be created first in the root of the app and must have execution permissions.

Code the docker-entrypoint.sh file.

#!/bin/bash -e
mvn package
exec $@

Include it as a docker entrypoint

ENTRYPOINT ["/docker-entrypoint.sh"]

By following this approach, we can significantly improve the efficiency of our Docker builds. The Maven dependencies will be downloaded and stored within the Docker volume, eliminating the need for repetitive downloads. Consequently, subsequent builds will be faster, more streamlined, and less error-prone.

Embracing Docker not only simplifies the development and deployment process but also ensures consistent and reliable results across different environments. With these techniques in place, you can confidently build, run, and maintain your Java Maven application within a Dockerized environment.

Following whole example step by step

Create app

run $:

mvn archetype:generate -DgroupId=dev.example -DartifactId=maven-docker-article -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Update pom.xml

<project  xmlns="http://maven.apache.org/POM/4.0.0"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>dev.example</groupId>
  <artifactId>maven-docker-article</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>maven-docker-article</name>
  <url>http://maven.apache.org</url>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>3.2.0</version>
        <configuration>
          <archive>
            <manifest>
              <mainClass>dev.example.App</mainClass>
            </manifest>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Add some code

package dev.example;
public class App 
{
    public static void main( String[] args )
    {
        System.out.println( "This app works and build fast using docker entrypoint and m2 repository volumne sharing" );
    }
}

Create Dockerfile

FROM maven:3.6.0-jdk-11 AS build

WORKDIR /app

COPY pom.xml .
COPY src ./src

COPY docker-entrypoint.sh /docker-entrypoint.sh

ENTRYPOINT ["/docker-entrypoint.sh"]

Create docker-entrypoint.sh file.

#!/bin/bash -e
env
mvn package
exec $@

Add execution permissions

chmod +x docker-entrypoint.sh

Build the image

docker build -t my-maven-java-app .

Execute the container/application

docker run --rm -v maven-cache:/root/.m2 maven-dev-article "java -jar /app/target/maven-docker-article-1.0-SNAPSHOT.jar"

With this command we are executing the java application inside its container and leveraging the maven repository shared by volume our docker volume maven-cache and the container maven repository /root/.m2

From now on you docker have a volume named maven-cache that can be used for whatever other maven app you want to dockerize using this same pattern.

Unleashing Performance: Silencing Searchkick for Record Updates in Ruby on Rails

Michel Sánchez Montells — Thu, 11 Jan 2024 04:23:09 +0000

You have your model configured for being indexed and searchable with searchkick but sometimes you want to update a record or many records or a bunch of records without triggering searchkick reindex. It is here...

INTRODUCTION

Many articles have been written about how to combine rails, elasticsearch, sidekiq, and redis because this is an almost obvious schema in Ruby on Rails applications.

When you want to have a model indexed and searchable with elastisearch you go mainly with the gem searchkick.

The basic, most used and first option suggested by documentation is:

 class Customer < ApplicationRecord
   searchkick searchable: %i[name lastname],
              filterable: %i[name],
              callbacks: :async

   def search_data
     {
       id: id,
       name: name,
       lastname: lastname
      }
   end
 end

It is supposed also you have sidekiq on the table and the environment variable REDIS_URL.

In this scenario

When you update a customer:

Customer.first.update(name: 'Jack')

then a sidekiq job is triggered for reindex this customer.

PROBLEM

When you update all customers having 30 000 records:

Customer.all.each_with_index{|customer, index| customer.update(name: "Jack-#{index}")

then 30 000 sidekiq jobs are triggered and enqueued for reindex all these customers

SOLUTION

You can update your bunch of customers silencing searchkick and once all updates are executed you can reindex all those customers.
Take a look:

Searchkick.callbacks(false) do
  Customer.all.each_with_index{|customer, index| customer.update(name: "Jack-#{index}")
end
Customer.reindex(mode: :async)

Searchkick.disable_callbacks
Customer.all.each_with_index{|customer, index| customer.update(name: "Jack-#{index}")
Searchkick.enable_callbacks
Customer.reindex(mode: :async)

In this way, once all customers are updated then some sidekiq jobs are being triggered each of them indexing a bunch of customers in a bulk giving you a huge improvement regarding performance and resources.

The second way is especially useful for test:

describe '#has_vacancies?' do
    subject(:event) { create :event, vacancies: 0 }

    before do
      Searchkick.disable_callbacks
    end

    after do
      Searchkick.enable_callbacks
    end

    context 'when vacancies lower than 1' do
      it 'return false' do
        expect(event.vacancies?).to eq false
      end
    end

    context 'when vacancies greater than 0' do
      it 'return true' do
        lesson.update(vacancies: 1)
        expect(event.vacancies?).to eq true
      end
    end
end

Parametrize Your Custom Bitbucket Pipeline With Variables

Michel Sánchez Montells — Sat, 30 Dec 2023 14:47:52 +0000

Bitbucket Pipelines provides a seamless integration for continuous integration and deployment (CI/CD) processes.

In this article, we'll go through the process of setting up a basic custom pipeline, using variables, and configuring default values for a smoother and more personalized workflow.

USE CASE

Sometimes we want to automate some amount of steps. Those steps will execute steps with different values.

One example I faced was to build automation for upgrading Postgres version.

The process consists of some regular steps. And the bitbucket pipeline may look like this:

pipelines:
  custom:
    - upgrade_postgres:
      - step:
        name: "some saving of old version"
        script:
          - ./dump_10.sh
      - step: 
        name: "Some steps for raising up new version"
        script:
          - ./load_11.sh

The process consists of some regular steps that only differ on the version I want to upgrade from (10) and the version I want to upgrade to (11).

Instead of changing the bitbucket-pipeline file, for every iteration of upgrading version, we can use variables.

pipelines:
  custom:
    - variables: #list variable names under here
       - name: UP_PG_FROM
         default: '11'
         allowed-values:
           - '11'
           - '12'
           - '13'
           - '14'
       - name: UP_PG_TO
         default: '12'
         allowed-values:
           - '12'
           - '13'
           - '14'
           - '15'   
    - upgrade_postgres:
      - step:
        name: "some saving of old version"
        script:
          - ./build_${UP_PG_FROM}.sh
      - step: 
        name: "Some steps for raising up new version"
        script:
          - ./build_${UP_PG_TO}.sh

Notice that in this snipped we set up variables with a set of possible values using keyword allowed-values and default values with keyword default

And we use those values with the syntax ${variable name}

This example could lead you to this once you click on Run Pipeline:

Exploring the Power of Keyword Arguments in Ruby

Michel Sánchez Montells — Sun, 26 Nov 2023 19:01:36 +0000

Keyword Arguments was introduced in Ruby 2.0.

This seems a very nice and attractive feature.

In a few words and code examples I will delve into keyword arguments in Ruby based on my own experience, opinion, and how I understand it.

This technique eliminates the Dependency on Parameter Order and Provide More Flexibility for Default Values.

🚥

Eliminating the Dependency on Parameter Order:

When using positional arguments, developers must know/remember the order in which the parameters are defined in the method definition. This can lead to confusion and errors, especially when methods have a large number of parameters. Keyword arguments eliminate this dependency by allowing developers to pass arguments by name instead of position. Let's consider an example:

With positional(traditional) parameters:

def greet(name, age)
  puts "Hello, #{name}! You are #{age} years old."
end

greet("Montells", 44)
> Hello, Montells! You are 44 years old.
greet(44, 'Montells')
> Hello, 44! You are Montells years old.

Here the developer must know the order of the parameters.

With hash options:

def greet(params)
  puts "Hello, #{params[:name]}! You are #{params[:age]} years old."
end

person = { name: 'Montells', age: '44' }
greet(person)
> Hello, Montells! You are 44 years old.
unordered_person = { age: '44', name: 'Montells' }
greet(unordered_person)
> Hello, Montells! You are 44 years old.

Here the dependency of order parameters is eliminated however developer needs to deal with hash.

With Keyword Arguments:

def greet(name:, age:)
  puts "Hello, #{name}! You are #{age} years old."
end

greet(name: "Montells", age: 44)
> Hello, Montells! You are 44 years old.
greet(age: 44, name: "Montells")
> Hello, Montells! You are 44 years old.

Here the developer must to know the name of each parameter but not the order.

Ease of Providing Default Values:

Keyword arguments also provide a convenient way to assign default values to parameters, regardless of their order. This is particularly useful when some parameters have default values and others do not. Let's illustrate this with an example:

With positional(traditional) parameters:

def create_user(name, age = 18, country = 'Unknown')
  puts "Name: #{name}, Age: #{age}, Country: #{country}"
end

create_user("Montells", "Cuba") # I want to omit age
> Name: Montells, Age: Cuba, Country: Unknown

With Keyword Arguments:

def create_user(name:, age: 44, country: 'Unknown')
  puts "User: #{name}, Age: #{age}, Country: #{country}"
end

create_user(name: "Montells", country: 'Cuba')
> User: Montells, Age: 44, Country: Cuba

In the first example, using positional arguments, we need to remember the order of the default parameters. However, in the second example, with keyword arguments, we can explicitly provide values only for the parameters we want to override, while the rest use their default values. This makes the code more flexible and less error-prone.

Bonus Track

Some similarity can be detected between hash and keyword arguments. Sometimes you have a hash options like {name: "Montells", country: 'Cuba'}. It can be passed to a method declared with keyword arguments using the double splat operator **

def create_user(name:, age: 44, country: 'Unknown')
  puts "User: #{name}, Age: #{age}, Country: #{country}"
end

hash_options = {name: "Montells", country: 'Cuba'}

create_user(**hash_options)
>User: Montells, Age: 44, Country: Cuba

🏁

Conclusion:
Keyword arguments in Ruby, introduced in version 2.0, offer significant advantages over traditional positional arguments. They eliminate the need to remember the order of parameters, making code more readable and self-explanatory. Additionally, keyword arguments provide a convenient way to assign default values to parameters, regardless of their order. By leveraging the power of keyword arguments, Ruby developers can write more expressive, flexible, and maintainable code.

Incorporating keyword arguments into your Ruby code can greatly enhance its readability and maintainability. Embrace this powerful feature and unlock the full potential of your Ruby programming skills. Happy coding!

Rails Models Files Organization

Michel Sánchez Montells — Fri, 03 Nov 2023 14:40:49 +0000

Just a place where to come back in the feature when I forget how to organize my Rails Models.

class MyModel < ActiveRecord::Base
  # extends 
  # includes 
  # relationships 
  # validations 
  # callbacks 
  # scopes 
  # delegates
  # additional config (i.e. accepts_nested_attribute_for etc...) 

  # class methods 
  # public instance methods 
  # protected instance methods 
  # private instance methods 
end

It is worth mentioning or thanks to this project rails_standards
The place where I found this guide.

Enhancing Dockerfile Flexibility: The Power of ARG Directives

Michel Sánchez Montells — Fri, 03 Nov 2023 03:40:14 +0000

ARG Directives: Enhancing Flexibility and Reducing Code Duplication

Docker is a powerful tool for containerization and deployment of applications. When creating Docker images, it's common to encounter scenarios where certain values need to be dynamic or configurable.

In this article, we'll explore how to improve the Dockerfile by leveraging ARG directives to make the Alpine version dynamic and avoid code duplication.

Let's start with the initial Dockerfile:

FROM alpine:3.18 as base

RUN echo "Alpine version 3.18"
RUN echo "Alpine version 3.18" > message.txt
CMD cat message.txt

FROM base as production

RUN echo "Alpine version 3.18"
RUN echo "Alpine version 3.18" > message.txt
CMD cat message.txt

build and run

$> docker build -t base --target base .
[base 2/3] RUN echo "Alpine version 3.18"
[base 3/3] RUN echo "Apline version 3.18" > message.txt     
$> docker run base
Apline version 3.18

If we do similar build an run with target production then

$> docker build -t production --target production .
[production 1/2] RUN echo "Alpine version 3.18" 
[production 2/2] RUN echo "Apline version 3.18" > message.txt
$> docker run production
Apline version 3.18

In the above Dockerfile, the Alpine version is hard-coded as 3.18, which leads to code duplication and lack of flexibility. We can improve this step by step using ARG directives.

Step 1: Dynamic Alpine Version in the FROM Directive

We can use the ARG directive to define an argument that can be expanded during the build process. Let's modify the first two lines as follows:

ARG ALPINE_VERSION
FROM alpine:${ALPINE_VERSION} as base

Now, during the Docker build command, we can pass the value for the ALPINE_VERSION argument using the --build-arg flag:

docker build -t base --target base --build-arg ALPINE_VERSION=3.18 .

This allows us to have a more flexible image where the Alpine version can be configured at build time.

Step 2: Default Value for Dynamic Alpine Version

We can provide a default value for the ALPINE_VERSION argument by modifying the first line as follows:

ARG ALPINE_VERSION='3.18'

Now, if the ALPINE_VERSION argument is not provided during the Docker build command, the default value will be used:

docker build -t base --target base .
docker run base
Apline version 3.18

Notice that the value 3.18 is used even when was not provided in the docker build command.

$> docker build -t base --target base --build-arg ALPINE_VERSION=3.17 .
[internal] load metadata for docker.io/library/alpine:3.17

Our build process use the value provided in the docker build command using the --build-arg flag

Step 3: Using the Same Value Inside a Build Stage

In the original Dockerfile, the ARG ALPINE_VERSION was not expanded inside the build stage. To make it accessible, we need to duplicate its definition inside the build stage. Modify the Dockerfile as follows:

ARG ALPINE_VERSION='3.18'
FROM alpine:${ALPINE_VERSION} as base

ARG ALPINE_VERSION
RUN echo "Alpine version ${ALPINE_VERSION}"
RUN echo "Alpine version ${ALPINE_VERSION}" > message.txt

Now, the ARG ALPINE_VERSION is accessible inside the build stage, and the default value is also available:

$> docker build -t base --target base .
[base 2/3] RUN echo "Alpine version 3.18"
[base 3/3] RUN echo "Apline version 3.18" > message.txt 
$> docker run base
Apline version 3.18

IMPORTANT: The line ARG ALPINE_VERSION . The ARG must be re-defined(duplicated) inside the build stage

Step 4: Using the Same Value Inside Different Build Stages

When Inherits

If build stages inherit from each other, they can access the arguments defined in their parent stage. Modify the Dockerfile as follows:

ARG ALPINE_VERSION='3.18'

FROM alpine:${ALPINE_VERSION} as base
ARG ALPINE_VERSION
RUN echo "Alpine version ${ALPINE_VERSION}"
RUN echo "Alpine version ${ALPINE_VERSION}" > message.txt
CMD cat message.txt

FROM base as production
RUN echo "Alpine version ${ALPINE_VERSION}"
RUN echo "Alpine version ${ALPINE_VERSION}" > message.txt
CMD cat message.txt

In this case, the build stage "production" inherits from "base," so it can access the arguments defined in the "base" stage without duplicating their definitions. The same value of ALPINE_VERSION will be used in both stages.

$> docker build -t production --target production .
=> CACHED [base 2/3] RUN echo "Alpine version 3.18"
=> CACHED [base 3/3] RUN echo "Apline version 3.18" > message.txt
=> [production 1/2] RUN echo "Alpine version 3.18" 
=> [production 2/2] RUN echo "Apline version 3.18" > message.txt
$> docker run production
Apline version 3.18

When no Inherits

If a build stage does not inherit from another stage, the arguments need to be duplicated inside that stage for access.

ARG  ALPINE_VERSION='3.18'

FROM  alpine:${ALPINE_VERSION}  as  base
ARG  ALPINE_VERSION
RUN  echo  "Alpine  version  ${ALPINE_VERSION}"
RUN  echo  "Apline  version  ${ALPINE_VERSION}"  >  message.txt
CMD  cat  message.txt

FROM  alpine:${ALPINE_VERSION}  as  staging
ARG  ALPINE_VERSION
RUN  echo  "Alpine  version  ${ALPINE_VERSION}"
RUN  echo  "Apline  version  ${ALPINE_VERSION}"  >  message.txt
CMD  cat  message.txt

ouput:

$> docker build -t staging --target staging .
=>[staging 3/3] RUN echo "Apline version 3.18"
> message.txt
$> docker run staging
Apline version 3.18

Notice: re-duplicate ARG ALPINE_VERSION

Summary

By using ARG directives, we can avoid code duplication and build more flexible Docker images.

ARGs defined outside build stages (before FROM) are accessible only in the lines with the FROM directive.
ARGs defined inside a build stage are accessible only within that stage and its child stages.
To access the value of an ARG defined outside from inside a build stage, duplicate its definition in the build stage.

Dealing with openssl when install old Ruby in recent Ubuntu

Michel Sánchez Montells — Fri, 15 Sep 2023 17:49:23 +0000

Many of you must have faced the problem of installing an old version of Ruby on a new Ubuntu.

Several threads throughout the internet demonstrate this, and various solutions have been shared.

The most common issue is the incompatibility with the OpenSSL version.

Among the most daunting solutions for non-expert Linux users is "compiling OpenSSL, installing it, and configuring Ruby to use this version." At least for me, that option is quite intimidating.

However, RVM provides a native solution.

ex: In ubuntu 22.04
trying to install ruby 2.7.4 like this

rvm install 2.7.4

will raise errors similar to this

/usr/share/rvm/rubies/ruby-2.5.0/lib/libruby.so.2.5(rb_vm_bugreport+0x4ae) [0x7f03e16b18ce]
/usr/share/rvm/rubies/ruby-2.5.0/lib/libruby.so.2.5(0xaafbd) [0x7f03e152ffbd]
/usr/share/rvm/rubies/ruby-2.5.0/lib/libruby.so.2.5(0x19e2e6) [0x7f03e16232e6]
/lib/x86_64-linux-gnu/libc.so.6(0x7f03e128e520) [0x7f03e128e520]
/lib/x86_64-linux-gnu/libssl.so.3(0x7f03df83e140) [0x7f03df83e140]

Solution that works for me

rvm pkg install openssl
rvm install 2.7.4 --with-openssl-dir=/usr/share/rvm/usr

I hope this helps you.

Things, tricks, hacks, workarounds...

Michel Sánchez Montells — Sun, 23 Apr 2023 19:55:58 +0000

The intention of this entry is just to group some small post which contain some tricks, hacks or solutions I found googling.

I am completely sure I will forget those solutions. Then I will use DEV as memory helper.

Several of this solutions will be useful also for other programmers if they happen to fall in the same situation.

Then this will help me a lot and also will help someone else.

Curl able to resume.

Michel Sánchez Montells — Sun, 23 Apr 2023 19:52:02 +0000

If you don't want to read:

Spolier

curl -L -O -C - 'https://internet-address/ubuntu-22.04.2-desktop-amd64.iso'

Some context

Writing this post with the goal knowing where to find out this again in the future and maybe help someone out there.

You can stay in the situation of downloading big file from internet using curl. And you can face the situation of bad connectivity and the downloading is interrupted continuously before ending and you need to start again.

Then you would like to be able of resume from the last byte.

The default or first curl command will looks like:

curl command

curl --header 'Host: mirrors.ircam.fr'
     --header 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36' 
     --header 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7' 
     --header 'Accept-Language: es-CU,es;q=0.9,en-US;q=0.8,en;q=0.7,es-419;q=0.6' 
     --header 'Referer: https://ubuntu.com/' 
     'https://mirrors.ircam.fr/pub/ubuntu/releases/22.04.2/ubuntu-22.04.2-desktop-amd64.iso' 
      -L -o 'ubuntu-22.04.2-desktop-amd64.iso'

This command will be downloading with file name ubuntu-22.04.2-desktop-amd64.iso however once the connection get closed after 600Mb of 3Gb if you retry the same command the downloading will start from 0.

Solution

curl command

curl --header 'Host: mirrors.ircam.fr' 
     --header 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36' 
     --header 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7' 
     --header 'Accept-Language: es-CU,es;q=0.9,en-US;q=0.8,en;q=0.7,es-419;q=0.6' 
     --header 'Referer: https://ubuntu.com/' 
     -L -O -C - 'https://mirrors.ircam.fr/pub/ubuntu/releases/22.04.2/ubuntu-22.04.2-desktop-amd64.iso'`

The parameter -C will ensure that the file is downloading like resuming, starting with the proper offset.
The parameter -O will assing to the downloaded local file name the same name of the remote file.

DEV Community: Michel Sánchez Montells

Copy & Paste PostgreSQL Query Results into Google Sheets (No CSV Needed)

But here’s the catch: 😕

🔧 How to do it (in seconds):

1. Open your terminal and start psql:

2. Set output to tab-separated format (what Google Sheets understands natively):

3. Run your query:

4. Copy the result from your terminal and paste it directly into Google Sheets.

How to Upgrade PostgreSQL with Docker Compose and Bitbucket Pipelines (Step-by-Step Guide)

Step 1: Adapt my docker-compose in the way that the specs involve the version.

Step 2: Deploy the app with the current approach

Step 3: Create a docker-compose file for the upgrade process

Step 4: The Bitbucket Pipeline

Step 5: Run this pipeline manually on bitbucket.

Step 6: Update your production docker compose and redeploy.

Conclusion

Writing Reusable and Performant Scopes in Rails with .merge

How to combine scopes in Rails in a DRY and efficient way?

The setup: authors and posts

The requirement

First solution: DRY, but with a subquery (less performance)

Second solution: efficient, but repetitive

Third solution: DRY and efficient with .merge

So… what does .merge actually do?

Does Rails run the scope first and then mix the results?

What exactly gets copied?

What if I try .merge without a join?

Can .merge break things?

Best practices for .merge

So… how should you think about .merge?

Accelerate Maven Application Builds: Maximizing Efficiency with Docker Volumes for Maven Repository Sharing

We can do it better.

Following whole example step by step

Create app

Update pom.xml

Add some code

Create Dockerfile

Create docker-entrypoint.sh file.

Add execution permissions

Build the image

Execute the container/application

Unleashing Performance: Silencing Searchkick for Record Updates in Ruby on Rails

INTRODUCTION

PROBLEM

SOLUTION

Parametrize Your Custom Bitbucket Pipeline With Variables

USE CASE

Exploring the Power of Keyword Arguments in Ruby

Eliminating the Dependency on Parameter Order:

With positional(traditional) parameters:

With hash options:

With Keyword Arguments:

Ease of Providing Default Values:

With positional(traditional) parameters:

With Keyword Arguments:

Bonus Track

Rails Models Files Organization

Enhancing Dockerfile Flexibility: The Power of ARG Directives

ARG Directives: Enhancing Flexibility and Reducing Code Duplication

Step 1: Dynamic Alpine Version in the FROM Directive

Step 2: Default Value for Dynamic Alpine Version

Step 3: Using the Same Value Inside a Build Stage

Step 4: Using the Same Value Inside Different Build Stages

When Inherits

When no Inherits

Summary

Dealing with openssl when install old Ruby in recent Ubuntu

Things, tricks, hacks, workarounds...

Curl able to resume.

1. Open your terminal and start `psql`:

Third solution: DRY and efficient with `.merge`

So… what does `.merge` actually do?

What if I try `.merge` without a `join`?

Can `.merge` break things?

Best practices for `.merge`

So… how should you think about `.merge`?