DEV Community: FaxriddinMaxmadiyorov

What’s the Difference Between count, size, and length in Ruby and Ruby on Rails?

FaxriddinMaxmadiyorov — Fri, 11 Jul 2025 16:06:20 +0000

In plain Ruby, there’s effectively no difference between count, size, and length when working with arrays or other collection-like objects — they all return the number of elements.

arr = [1, 2, 3]
arr.count   # => 3
arr.size    # => 3
arr.length  # => 3

However, in Ruby on Rails, particularly when dealing with ActiveRecord associations or query objects, these methods behave very differently under the hood — especially in terms of performance and when they trigger database queries.

Understanding these differences is crucial when you're working with large datasets or optimizing performance in a Rails application.

Let's take an example:

users = User.where(active: true)
users.class # User::ActiveRecord_Relation # its returns ActiveRecord, does not execute the query in this stage

At this point, users is an ActiveRecord::Relation, not an array. That means the database query has not been executed yet — it's just a representation of the query to be run later.

This is a key feature of ActiveRecord: lazy loading. The query will only be executed when the data is actually needed — for example, when you iterate over the records, call .to_a, or use .length.

.count

Since users is an ActiveRecord::Relation, calling .count on it will immediately execute a SQL COUNT(*) query to count the number of matching records — without loading the actual records into memory.

[51] pry(main)> users.count
   (0.6ms)  SELECT COUNT(*) FROM "users" WHERE "users"."active" = $1 /*application:Pixie*/  [["active", true]]
=> 32

This is efficient when you only need the number of records, not the records themselves.

Note: .count always queries the database, even if the relation was previously loaded.

.length

The .length method always loads the records into memory and then calculates the number of elements by calling Array#length.

users = User.where(active: true)
users.length  # => runs SELECT * FROM users WHERE active = true

This converts the relation into an array and then returns the number of elements.

Important: This can be inefficient for large datasets because it loads all matching records into memory, even if you only need the count.

Use .length only when you actually need the full records — for example, if you're going to iterate over them right after.

.size

The .size method is smart — it adapts based on whether the records have already been loaded into memory.

If the records are already loaded, .size simply returns the number of records in memory:

users.loaded?
# => true

users.size
# => 32  (No additional SQL query is executed)

If the records are not yet loaded, .size behaves like .count and runs a SQL COUNT(*) query:

users.loaded?
# => false

users.size
# => Executes:
# SELECT COUNT(*) FROM "users" WHERE "users"."active" = $1
# => 32

This makes .size the most efficient and flexible choice in many cases — it avoids unnecessary queries but still gives an accurate count.

Chat Server in Ruby Sockets

FaxriddinMaxmadiyorov — Sun, 28 Jul 2024 18:14:48 +0000

I am going to build a chat server in Ruby's sockets library. Before this, let's clarify what sockets are. Sockets are the endpoints of the communication channels. There are two types of sockets:

Stream sockets - These sockets use Transmission Control Protocol (TCP) for communication. They provide a reliable, connection-oriented communication channel. Web servers and clients (HTTP/HTTPS) use this kind of sockets.
Datagram sockets - These sockets use User Datagram protocol for communication. They are less reliable than TCP sockets and are used in streaming.

Chat application contains two parts: server and client; We will organize server part first:
Create TCPServer, it accepts infinite signals, i.e it must be alive, exchange data.
Create Socket client, it connects to server, exchange data

Our first example shows synchronous chat (chat and clients sides have to wait each other to send a message, each side of the connection waits for the other to send a message before it proceeds, creating a sort of "deadlock" where both sides are waiting.)

# server.rb
require 'socket'

server = TCPServer.new('localhost', 3333)
puts "TCPServer is running port on 3333 ..."

client = server.accept
puts "Client connected."

loop do
  message = client.gets.chomp
  puts "Client: #{message}"
  break if message == 'exit'

  response = gets.chomp
  client.puts response
  break if response == 'exit'
end

client.close
puts "Client disconnected."

# client.rb
require 'socket'

client = TCPSocket.new('localhost', 3333)
puts "Connected to server..."

loop do
  message = gets.chomp
  client.puts message

  # Exit if the message is 'exit'
  break if message == 'exit'

  # Receive and print the server's response
  response = client.gets.chomp
  puts "Server: #{response}"
  break if response == 'exit'
end

client.close
puts "Disconnected from server."

To deliver messages in correct order, we have to use Threads to handle other tasks concurrently (the server accepts only one client).

require 'socket'

server = TCPServer.new('localhost', 3333)
puts "TCPServer is running port on 3333 ..."

client = server.accept
puts "Client connected."

# Thread to handle reading messages from the client
Thread.new do
  loop do
    message = client.gets.chomp
    puts "Client: #{message}"
    break if message == 'exit'
  end
end

# Thread to handle sending messages to the client
loop do
  response = gets.chomp
  client.puts response
  break if response == 'exit'
end

client.close
puts "Client disconnected."

require 'socket'

client = TCPSocket.new('localhost', 3333)
puts "Connected to server..."

# Thread to reading messages from the server
Thread.new do
  loop do
    message = client.gets.chomp
    puts "Server: #{message}"
    break if message == 'exit'
  end
end

loop do
  response = gets.chomp
  client.puts response
  break if response == 'exit'
end

client.close
puts "Disconnected from server."

If we want our server can communicate to all clients at the same time, we should create 1 thread (to handle communication) for each client and 1 server thread (to handle server-side input and broadcasts). As to client side, we have to create one thread to handle incoming message.

# server.rb
require 'socket'

server = TCPServer.new('localhost', 3333)
puts "TCPServer is running on port 3333 ..."

clients = []

def broadcast(message, clients, sender = nil)
  clients.each do |client|
    client.puts message unless client == sender
  end
end

# Thread to handle server input
server_input_thread = Thread.new do
  loop do
    response = gets
    break if response.nil? || response.chomp == 'exit'

    message = "Server: #{response.chomp}"
    broadcast(message, clients)
  end
  puts "Server shutting down."

  clients.each { |client| client.close } # Close all client connections
  server.close
  exit
end

loop do
  client = server.accept
  clients << client
  puts "Client connected."

  Thread.new(client) do |client_socket|
    begin
      loop do
        message = client_socket.gets
        break if message.nil? || message.chomp == 'exit'

        message = "Client: #{message.chomp}"
        puts message
      end
    rescue StandardError
      puts "Client disconnected."
    ensure
      clients.delete(client_socket)
      client_socket.close
      puts "Client disconnected."
    end
  end
end

# client.rb
require 'socket'

client = TCPSocket.new('localhost', 3333)
puts "Connected to server..."

# Thread to reading messages from the server
Thread.new do
  loop do
    message = client.gets&.chomp
    puts message
    break if message == 'exit'
  end
end

loop do
  response = gets.chomp
  client.puts response
  break if response == 'exit'
end

client.close
puts "Disconnected from server."

SOLID Design Principles in Ruby

FaxriddinMaxmadiyorov — Tue, 02 Jul 2024 04:57:04 +0000

SOLID - dasturni yanada tushunarli, o'zgartirishga va kattalashtirishga imkon beruvchi principlar yig'indisi.

Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

1. Single Responsibility Principle
Har bir class faqatgina bitta funksionalga javob berishi kerak. Ko'p funksional'larni bitta class'da yozilgan bo'lsa, o'sha classni o'zgartirish hamma funksionallarni o'zgartirishga olib kelishi mumkin.

class Employee
  def process_data
  end

  def send_message(message)
  end
end

masalan, bizda Employee class bor, unda process_data va send_message method'lari mavjud. send_message method'ga o'zgartirish kerak bo'lsa, Employee classni ichida o'zgartirishga to'g'ri keladi. Bundan tashqari, mijozlarga ham message yuborish kerak bo'lsa, Client class'ni ichida ham send_message methodini yozishimizga to'g'ri keladi.

class Employee
  def process_data; end
end

class Client
  def process_data; end
end

class Message
  def send_message(user, message)
  end
end

Agar yuboriladigan message o'zgartirilishi kerak bo'lsa, Message classni ichida o'zgartirishimiz kifoya.

2. Open/Closed Principle (OCP)
Classlar kengaytirish uchun ochiq, lekin o'zgartirish yoki refaktor qilish uchun yopiq bo'lishi kerak. Bu printsip classni imkoniyatini oshirish uchun allaqachon ishlab turgan classni o'zgartirmaslikni eslatadi. Masalan bizda InvoiceReport class bor, u hozircha orderni pdf va csv formatlarda generate qiladi.

class InvoiceReport
  def initialize(order, type)
    @order = order
    @type = type
  end

  def generate
    case @type
    when 'pdf'
      # pdf generation
    when 'csv'
      # csv generation
    end
  end
end

Endi xls formatda ham report generate qilmoqchimiz, va InvoiceReport classga qo'shishimiz kerak. Buni oldini olish uchun Open/Closed Principle ishlatishimiz mumkin:

class InvoiceReport
  def initialize(order, klass)
    @order = order
    @klass = klass
  end

  def generate
    @klass.new(@order).generate
  end
end

class PdfGenerator
  def initialize(order)
    @order = order
  end

  def generate
    # Generate PDF report
    puts "PDF Report generated"
  end
end

class CsvGenerator
  def initialize(order)
    @order = order
  end

  def generate
    # Generate CSV report
    puts "CSV Report generated"
  end
end

3. Liskov Substitution Principle
if S could be a sub-type of T, then objects of type T is also replaced with objects of type S - Agar S class T classni child classi bo'lsa, T classni obyektlari S classni obyektlari bilan muvofiq bo'lishi kerak.

class User
  attr_accessor :name

  def initialize(name)
    @name = name
  end

  def report
    raise 'Not implemented for User class'
  end
end

class Employee < User
  def initialize(name)
    super
  end

  def report
    puts "Report method called!!!"
  end
end

Agar child class o’zining ota class’i bilan bir xil amallarni bajara olmasa, bu xatolarga olib kelishi mumkin.

Agar sizda class mavjud bo’lsa va undan yangi yangi class yaratsangiz, u parent (ota) va yangi class esa child (farzand) class bo’ladi. Child class ota class bajara olgan barcha narsani qila olishi kerak. Bu jarayon Inheritance deyiladi.

Child class bir xil so’rovlarni qayta ishlashi va parent class bilan bir xil yoki bir turdagi natijani berishi kerak.

Ushbu tamoyil asosiy sinf yoki uning pastki sinfi hech qanday xatosiz bir xil tarzda ishlatilishi uchun o’zgarmaslikni ta’minlashga qaratilgan.

4. Interface Segregation
Interface Segregation tamoyili client ishlatmaydigan methodga bog'liq bo'lmasligini aytadi. Boshqacha qilib aytganda, bitta umumiy katta interfeysdan ko'ra classni o'zigagina tegishli interfeyslar yaratish g'oyasini qo'llaydi.

module PrinterFunctions
  def print

  end

  def scan

  end

  def fax

  end
end

class Printer
  include PrinterFunctions
end

hamma printerlar scan yoki fax funksiyasini qo'llab quvvatlay olmaydi, va bu misol ISP ni buzadi.

module PrintFunctions
  def print

  end
end

module ScanFunctions
  def scan

  end
end

module FaxFunctions
  def fax

  end
end

class Samsung
  include PrintFunctions
  include ScanFunctions
end

Endi client o'ziga kerakli methodlarni ishlata oladi.

5. Dependency Inversion Principle
High-level class'lar low level class'larga qaram bo'lmasligi kerak. Har ikkalasi ham abstraktsiyaga qaram bo'lishi kerak. Dependency Inversion Liskov Substitution and Open-Closed principlari jamlanmasi.

class NotificationService
  def notify_via_email(message)
    # EmailNotifier classga to'g'ridan to'g'ri bog'liq
    email_notifier = EmailNotifier.new
    email_notifier.send_email(message)
  end
end

class EmailNotifier
  def send_email(message)
    puts "Sending email with message: #{message}"
    # Logic to send an email
  end
end

notification_service = NotificationService.new
notification_service.notify_via_email('Hello via Email!')

bu yerda muammolar:

NotificationService EmailNotifier classga bog'liqligi
Yangi Notification type qo'shmoqchi bo'lsak, NotificationService classga o'zgartirish kiritishga to'g'ri keladi. Bu muammolarni Dependency Inversion prinsipiga binoan hal qilsak:

# notifier.rb, Abstraksiya yaratish
module Notifier
  def send_message(message)
    raise NotImplementedError, 'You must implement the send_message method'
  end
end

class EmailNotifier
  include Notifier

  def send_message(message)
    puts "Sending email with message: #{message}"
    # Logic to send an email
  end
end

# notification_service.rb, Notifier abstraksiyasini ishlatish
class NotificationService
  def initialize(notifier)
    @notifier = notifier
  end

  def notify(message)
    @notifier.send_message(message)
  end
end

email_notifier = EmailNotifier.new
notification_service = NotificationService.new(email_notifier)
notification_service.notify('Hello via Email!')

Bu bilan yuqori darajadagi class undan pastroq darajadagi classga bog'liq bo'lmaydi.

PayPal REST API

FaxriddinMaxmadiyorov — Sat, 13 Apr 2024 08:48:31 +0000

In this article, I will explain how to integrate the PayPal REST API. First of all, we should create a sandbox account on PayPal at developer.paypal.com.

Authentication
As written in the documentation, we have 2 options to authenticate our request to sandbox server:

get a bearer token:

curl -v -X POST "https://api-m.sandbox.paypal.com/v1/oauth2/token"\
 -u "CLIENT_ID:CLIENT_SECRET"\
 -H "Content-Type: application/x-www-form-urlencoded"\
 -d "grant_type=client_credentials"

encryption of CLIENT_ID:CLIENT_SECRET in Base64

Base64.strict_encode64("#{PAYPAL_CLIENT_ID}:#{PAYPAL_CLIENT_SECRET}")

We will get access_token in both ways. I will write business logic in active interactions.

We need to set 2 endpoints to proceed a payment with Paypal: 1) create order 2) execute order;

Order
We should create an order;

create_order.rb

request_path = BASE_URL + '/v2/checkout/orders'
HTTParty.post(request_path, headers: headers, body: your_body.to_json)

There are two options for intent:

AUTHORIZE
CAPTURE

When you set the intent to "AUTHORIZE," PayPal authorizes the payment amount but doesn't capture the funds immediately. Instead, it places a hold on the funds, reserving them for capture at a later time. This is useful in scenarios where you need to verify the availability of funds or perform additional checks before completing the transaction.
Use Case: For example, if you operate an e-commerce platform, you might use the "AUTHORIZE" intent when a customer places an order. This allows you to verify the payment details and inventory availability before confirming the purchase and capturing the funds.

CAPTURE: With the "CAPTURE" intent, PayPal immediately captures the funds from the customer's account when the payment is made. This completes the transaction in real-time, and the funds are transferred to your account.
Use Case: In scenarios where you provide digital goods or instant services, using the "CAPTURE" intent ensures that payments are processed and funds are transferred immediately upon completion of the transaction.

If we create an order with "AUTHORIZE" intent, then we have to authorize (Authorize Order method, Orders API) the order then capture the order (Capture Authorized Payment, Payments API); If we create an order with "CAPTURE" intent, then we directly use Capture Payment for Order method (Orders API);

We will use "CAPTURE" intent here.

CAPTURE

request_path = BASE_URL + '/v2/checkout/orders/{id}/capture'
HTTParty.post(request_path, headers: headers, body: your_body.to_json)

that is all.

Subscriptions

When we visit Netflix.com, we can see monthly plans; Every month, some money is withdrawn from our card. How can it happen by itself? Here comes webhooks. A webhook is an HTTP request triggered by an event in a source system and sent to a destination system. When money is withdrawn, PayPal sends a notification to our server. We need an endpoint to receive a POST request from Paypal and add it in "Add Webhook" section. It is not possible to set localhost url, if you want to test in your localhost, then you can use ngrok. We need to return a response with 200 status code if everything is ok, else failure. Otherwise it keeps sending a request to our server.

class WebhooksController < ApplicationController
  skip_before_action :verify_authenticity_token, only: :checkout_webhook

  def checkout_webhook
    render plain: '', status: :ok
  end
end

Product and Plan should be created for a Subscription.

create_product.rb

request_path = BASE_URL + '/v1/catalogs/products'
HTTParty.post(request_path, headers: headers, body: your_body.to_json)

create_plan.rb

request_path = BASE_URL + '/v1/billing/plans'
HTTParty.post(request_path, headers: headers, body: your_body.to_json)

create_subscription.rb

request_path = BASE_URL + '/v1/billing/subscriptions'
HTTParty.post(request_path, headers: headers, body: your_body.to_json)

After subscription is created successfully, its status will be APPROVAL_PENDING. After clicking the button, the status will be active.