DEV Community: José Anchieta

Easy Queue implementation in Ruby

José Anchieta — Tue, 21 Nov 2023 15:21:01 +0000

This post contains some info from the ChatGPT.

You might think, "Queues aren't used much in Ruby," and it's true, you don't often see a queue implementation in Ruby or Rails projects. But for me, the time has passed when I cared about whether I'll use something in my career or not. I just want to have the knowledge, and I advise you reading this post to do the same, you'll never know when you're going to need it and I believe these things are what make a big difference in our career.

The Queue is a linear and dynamic data structure, following the FIFO (First In, First Out) principle. This means the first element to enter is the first to leave. Think of a line of people at a bank: the first one in line gets served first.

Key characteristics:

Ordered insertion and removal: Elements are added at the end of the queue and removed from the beginning.

Basic operations:

Enqueue: Add an element at the end of the queue, update the tail reference, and update the item count.
Dequeue: Remove the element from the beginning of the queue, update the head reference, and update the item count.
Peek/Front: Check out the first element of the queue without removing it.

Usage

Ideal for situations requiring processing in the order of arrival, such as resource management in computing or customer service.

Implementation: Can be implemented with arrays or linked lists. The simplicity and efficiency of the Queue make it a popular choice in various software applications.

Queues, like Linked Lists, require a container to hold the data within the structure, in this case, Nodes.

A classic example of using queues in software development is managing asynchronous tasks or messages. This is especially common in distributed systems and web applications, where operations can be deferred and executed outside the main flow to avoid blocking processing.

For example, in an e-commerce application, when a user places an order, the order confirmation and payment processing might be added to a queue. Meanwhile, the user gets an immediate response that their order has been received. In the background, services processing payments and updating inventory consume these tasks from the queue, processing them sequentially.

This allows the application to handle demand spikes more efficiently, spreading the workload over time, and ensuring that critical operations are completed reliably and in order.

Implementation

This implementation is not focused on performance, but on being easy to understand.


# One of the smallest data structures we can have,
# a simple Node acting like a container to wrap our data.

class Node
  attr_accessor :value, :next_value

  def initialize(value)
    @value = value            # Wrapped data
    @next_value = nil         # Reference to next starts nil    
  end
end

# The Queue implementation

class Queue
  attr_accessor :length, :head, :tail

  def initialize
    @length = 0
    @head = nil
    @tail = nil
  end

  def enqueue(value)
    node = Node.new(value)  # Create a new node
    @length += 1            # Update the Queue length 

    if @head.nil?           # Check if head is nil
      @head = @tail = node  # Set the new node as head and tail
      return                # ends the enqueue
    end

    @tail.next_value = node # Keeping the references
    @tail = node            # Tail receives the new node
  end

  def dequeue
    return nil if head.nil? # Nothing to dequeue

    @length -= 1            # Update length to -1

    head = @head            # Save current head in a variable
    @head = head.next_value # Update head to the second item

    # head.next_value = nil # Breaks link between the old head
                            # required in non GC languages

    head.value              # Return the removed value
  end

  def peek
    return nil if head.nil? # Checking again if head is nil

    head.value              # Returns the head value
  end
end

# Always a good idea having some automated tests :)

require 'rspec/autorun'

describe '#enqueue / #dequeue / #peek' do
  it 'has the Jose value' do
    q = Queue.new
    q.enqueue('Jose')
    expect(q.peek).to eq('Jose')
    expect(q.length).to eq(1)

    q.enqueue('Mary')
    expect(q.peek).to eq('Jose')
    expect(q.length).to eq(2)

    q.dequeue
    expect(q.peek).to eq('Mary')
    expect(q.length).to eq(1)
  end
end

Hope you like it.

Ruby on Rails Pessimistic Locking

José Anchieta — Wed, 02 Dec 2020 16:44:48 +0000

Let's say we have two users and we want to create a money transfer between these users, but we have to make sure that if there is an error in any of the steps, the execution will be canceled and other transactions will only be executed when the current transaction ends, this is also known as Race Condition.

To solve this problem or similar problems, there is a technique in Rails called Pessimistic Lock or Pessimistic Strategy, it provides a row-level locking in SQL like SELECT … FOR UPDATE and others and it uses ActiveRecord Transactions. Let's take a look at this code:

def transfer_money_from_user_to_user(user1, user2)
  # Charge 200 from the user1...
  user1.balance(-=200)
  user1.save! # Callbacks and other things...
  # and pay the user2
  user2.balance(+=200)
  user2.save! # Callbacks and other things...
end

If for some reason, the first transaction (charge from user1) fails, it will not prevent the second one to be executed. We have two ways to prevent this using Rails, lock! and with_lock, let's take a look:

Lock!

Using Transactions and lock! we could do something like:

def transfer_money_from_user_to_user(user1, user2)
  # Initialize an ActiveRecord Transaction
  ActiveRecord::Base.transaction do
    # Lock the users
    user1.lock!
    user2.lock!
    # Charge 200 from the user1...
    user1.balance(-=200)
    user1.save!

    # Pay the user2
    user2.balance(+=200)
    user2.save!
  end
end

With_lock

With_lock simplifies our code and creates a transaction wrapper:

def transfer_money_from_user_to_user(user1, user2)
  user1.with_lock do
    # Charge 200 from the user1...
    user1.balance(-=200)
    user1.save!

    # Pay the user2
    user2.balance(+=200)
    user.save!
  end
end

That's it. Using Pessimistic Locking inside Rails is a good way to prevent these kind of failures. See you!

Download a CSV file from Heroku using Rails console

José Anchieta — Thu, 26 Nov 2020 15:25:26 +0000

If you need to download some data from Heroku as i did, here is a helpful command to do it.

First, i will create a Ruby file to execute what i need in the Rails console, for example:

report = CSV.generate do |csv|
  csv << ["name", "email"]

  users = User.where(
    :created_at => Date.parse("01-11-2020")..Date.parse("30-11-2020")
  )

  users.each do |user|
    csv << [user.name, user.email]
  end
end

STDOUT.puts report

In this case, i'm selecting all users created from November 1st until the 30th of November and exporting a csv file with all users names and emails.

In order to run this script in a Heroku Rails console and download this CSV file, we are going to use the Rails runner command.

cat users.rb | heroku run --no-tty --app=heroku-app-name -- bin/rails runner - > users.csv

If you have NewRelic installed in your Rails application on Heroku, probably you will get some limes from it inside your CSV file. To fix that, add this grep option in our command:

cat users.rb | heroku run --no-tty --app=heroku-app-name -- bin/rails runner - | grep -v "\*\* \[NewRelic\]" > users.csv

That's it.