Forem: Vladislav Kopylov

Параллелизм в ruby 2: ограничиваем потоки

Vladislav Kopylov — Sat, 14 Mar 2026 16:22:14 +0000

В продолжении первой части, где мы знакомились с тредами, пора расширять функционал. В мире микросервисов надо всегда помнить, что внешняя среда может быть нестабильной. Хорошей энтерпрайз практикой при обращении во внешний сервис является выставление таймаутов на запрос и выставление таймаутов на саму нашу ручку. Так как мы пишем серьезный агрегатор, то давайте поставим ограничение на 1 секунду для исходящего запроса и 2 секунды на ответ нашей ручки-агрегатора. В итоге ручка контроллера будет выглядеть так:

def test3
  results = {}
  threads = URLS.map do |name, url|
    Thread.new do
      resp = Faraday.get(url) do |req|
        req.options.timeout = 1
        req.options.open_timeout = 1
      end
      results[name] = JSON.parse(resp.body)
    end
  end

  # NOTE: timeout на всю текущую ручку
  Timeout.timeout(2) do
    threads.map(&:value)
  end

  render json: { success: true, **results }, status: :ok
rescue Faraday::TimeoutError, Timeout::Error, Timeout::ExitException => e
  render json: { success: false, error: "#{e.class} -> #{e.to_s}" }, status: :gateway_timeout
end

Ручка работает и отдает такой же результат

$ curl  http://localhost:3000/api/v1/test3
{"success":true,"a3":{"success":true,"name":"third"},"a1":{"success":true,"name":"first"},"a2":{"success":true,"name":"second"}}%

Пока что наш сервис-агрегатор никаких проблем не представляет. Но представим, что со временем наш сервис увеличивается. У него появляются дополнительные ручки, он масштабируется, и становится все популярнее. Мы поднимаем больше воркеров и у него увеличивается кол-во производственных мощностей.

При данном сценарии появляется проблемы, если сервисы, к которым мы обращаемся, растут не так быстро или они сами время от времени находятся под нагрузкой. Это ситуацию мы будем сейчас симулировать. Нам нужно чтобы внешние ручки отваливались, поэтому для симуляции увеличиваем треды до 10

RAILS_ENV=production RAILS_LOG_LEVEL=debug RAILS_MAX_THREADS=10 bin/rails s -P aggregator

Так как просто запускать wrk не интересно, а хочется иметь лог ответа, то делаем lua-скрипт для чтения 500-х:

-- status.lua
function response(status, headers, body)
  if status >= 500 then
    io.write("\n=== 5xx ===\n")
    io.write("status: " .. status .. "\n")
    io.write(body .. "\n")
    io.write("=== /5xx ===\n")
  end
end

Даем нагрузку под 10 потоков

$ wrk -t2 -c10 -d30s -s status.lua --latency http://localhost:3000/api/v1/test3 > stdout.txt
Running 30s test @ http://localhost:3000/api/v1/test3
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   807.54ms   58.24ms 838.73ms   97.93%
    Req/Sec     6.95      4.71    20.00     83.61%
  Latency Distribution
     50%  814.50ms
     75%  817.30ms
     90%  820.39ms
     99%  836.53ms
  368 requests in 30.08s, 179.83KB read
  Socket errors: connect 0, read 0, write 0, timeout 30
  Non-2xx or 3xx responses: 359
Requests/sec:     12.23
Transfer/sec:      5.98KB

Мы так и остались в пределах 15 rps, но к тому же у нас посыпались 500-е ошибки. В файле stdout.txt видны ошибки Faraday::TimeoutError - Net::ReadTimeout with TCPSocket:(closed). Это потому что с увеличением кол-во клиентов мы кратно увеличиваем и нагрузку на слабенький внешний сервис.

Добавляем thread pool

Ограничение производительности внешних сервисов не должно влиять на наше приложение, поэтому мы напишем thread pool чтобы ограничить исходящие запросы. Напишем исходящую очередь при помощи библиотеки concurrent-ruby

module AppThreadPool
  # 1 worker × 5 threads
  POOL = Concurrent::FixedThreadPool.new(5) # 5 исходящих потоков
end

# хорошей практикой дождаться завершения пула при завершении процесса
Rails.application.config.after_initialize do
  at_exit do
    AppThreadPool::POOL.shutdown
    AppThreadPool::POOL.wait_for_termination(5)
  end
end

Переписываем нашу ручку в контроллере чтобы она использовала созданный пул для внешних запросов.

def test4
  results = {}
  futures = URLS.transform_values do |url|
    Concurrent::Promises.future_on(::AppThreadPool::POOL) do
      resp = Faraday.get(url) do |req|
        req.options.timeout = TEST3_REQ_TIMEOUT
        req.options.open_timeout = TEST3_REQ_TIMEOUT
      end
      JSON.parse(resp.body)
    end
  end

  Timeout.timeout(TEST3_TIMEOUT) do
    results = futures.transform_values(&:value!)
  end
  render json: { success: true, **results }, status: :ok
rescue Faraday::TimeoutError, Timeout::Error, Timeout::ExitException => e
  render json: { success: false, error: "#{e.class} -> #{e.to_s}" }, status: :gateway_timeout
end

Проверяем работу ручку

curl http://localhost:3000/api/v1/test4
{"success":true,"a1":{"success":true,"name":"first"},"a2":{"success":true,"name":"second"},"a3":{"success":true,"name":"third"}}%

Снова запускаем нагрузочные тесты на 10 потоков

$ wrk -t2 -c10 -d30s -s status.lua --latency http://localhost:3000/api/v1/test4 > stdout.txt
Running 30s test @ http://localhost:3000/api/v1/test4
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   857.90ms   65.56ms 991.34ms   97.39%
    Req/Sec     7.57      5.23    20.00     73.12%
  Latency Distribution
     50%  866.29ms
     75%  870.38ms
     90%  873.68ms
     99%  878.57ms
  345 requests in 30.08s, 192.71KB read
Requests/sec:     11.47
Transfer/sec:      6.41KB

Мы видим, что latency сохранился и пропали 500-е ошибки. Ошибок нет потому что мы не DDOS'им внешний сервис, а даем ему нагрузку по силам

Что вообще произошло

Ручка test3 создавала треды через Thread.new do и никак не ограничивала их исходящее кол-во. Наш пул AppThreadPool::POOL как раз ограничивал размер исходящих потоков.

Давайте подробнее посмотрим на работу внешнего сервиса под нагрузкой. Запускаем wrk

wrk -t2 -c10 -d20s --latency http://localhost:3000/api/v1/test3

И параллельно смотрим время ответа

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 0.885654s
http: 200

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 1.007139s
http: 200

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 1.309763s
http: 200

Ответ от ручки /second стал больше чем 200ms. При этом со стороны рельсовых логов все ОК:

[f92379c0-0a68-43d6-bec9-7912aa2dd25d] Completed 200 OK in 205ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)
[01247d48-b605-49dc-8439-7dd88b289808] Completed 200 OK in 205ms (Views: 0.1ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)
[3a3f66d6-dd88-4c11-8cc9-8f54e82dbb9d] Completed 200 OK in 205ms (Views: 0.2ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 0.0ms)

Это потому, что рельса трекает именно те запросы, что уже попали в нее, именно это мы и видим в логах. В настоящем развернутом приложении, перед рельсов стоит веб-сервер. В нашем случае - это puma, со своей очередью в 1024 запроса. А перед веб-сервером будет стоять как минимум один nginx. Так что если вас интересует время ответа близкое к тому, что видит пользователь, то лучше смотреть не по логам рельсы, а по логам nginx.

А какое поведение через треды? Запускаем тесты

$ wrk -t2 -c10 -d30s --latency http://localhost:3000/api/v1/test4

И параллельно смотрим время ответа.

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 0.288457s
http: 200

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 0.208960s
http: 200

Та как мы теперь не DDOS'им внешний сервирс, то мы видим нормальное время ответа - все в норме.

Получается, что с внешним пулом у нас следующая схема работы. У нас есть приложение. Мы запускаем 1 воркер пумы в 10 потоков. Он из своей очереди вытаскивает запросы и может передавать только 10 тредов в приложении. Но не смотря на эти 10 входящих тредов, наружу во внешний сервис приложение отдаем всего 5 потоков. В результате мы ограничиваем исходящую от нас нагрузку не в ущерб нагрузки на наш агрегатор.

Добавляем еще энтерпрайза

Раз у нас микросервисы и внешние зависимости - значит внешний мир нестабильный. Внешние сервисы могут деградировать, но это не должно влияет на производительность нашего сервиса. Если при недоступности одного сервиса наша ручка не должна ломаться, то можно реализовать partial response

Допустим, ручка second не очень важна и в целом его ответом можно пренебречь, значит мы выбираем стратегию partial response на случай отказов. Для того мы можем сделать отдельный исходящий пул для ручки second

module AppThreadPool
  # старый единый исходящий пул
  POOL = Concurrent::FixedThreadPool.new(5) # исходящих

  # пул для быстрых ручек (first + third)
  FAST = Concurrent::FixedThreadPool.new(6)
  # пул для медленных ручке (second)
  SLOW = Concurrent::FixedThreadPool.new(3)
end

Напишем код в контроллере чтобы проверить какое будет поведение с одним и с двумя пулами

# переместим slow в конце тк он наименее ценный
URLS2 = {
  a1: ['http://localhost:4000/api/v1/services/first',  :fast],
  a3: ['http://localhost:4000/api/v1/services/third',  :fast],
  a2: ['http://localhost:4000/api/v1/services/second', :slow]
}

def test5
  deadline = Concurrent.monotonic_time + 1.2 # дедлайн всей ручки агрегатора (partial response)
  futures = URLS2.transform_values do |(url, kind)|
    if params[:pool] == '1' # будем выбирать 1 или 2 пула по get-параметру
      pool = AppThreadPool::POOL
    else
      pool = (kind == :slow) ? AppThreadPool::SLOW : AppThreadPool::FAST
    end

    Concurrent::Promises.future_on(pool) do
      resp = Faraday.get(url) do |req|
        req.options.timeout = 2.0 # таймаут на запрос
        req.options.open_timeout = 0.1
      end
      { ok: true, data: JSON.parse(resp.body) }
    rescue Faraday::Error => e
      { ok: false, error: "#{e.class}: #{e.message}" }
    rescue StandardError => e
      { ok: false, error: "#{e.class}: #{e.message}" }
    end
  end

  results = {}
  futures.each do |name, f|
    remaining = deadline - Concurrent.monotonic_time
    if remaining <= 0
      results[name] = { ok: false, error: "deadline_exceeded" }
      next
    end
    # ждём конкретный future не дольше оставшегося времени
    v = f.value(remaining)
    results[name] = v || { ok: false, error: "deadline_exceeded" }
  end

  render json: { success: true, partial: results.any? { |_k, v| v[:ok] == false }, results: results }, status: :ok
end

Запускам наш сервис агрегатор

RAILS_ENV=production RAILS_LOG_LEVEL=debug RAILS_MAX_THREADS=10 bin/rails s -P aggregator

Для первого эксперимента убеждаемся, что ручка отвечает за 0.2 секунды и она стабильная

def second
  sleep(0.2)
  render json: { success: true, name: __method__ }, status: :ok
end

Тестируем ответ когда все хорошо

# один пул
$ wrk -t2 -c10 -d30s --latency  http://localhost:3000/api/v1/test5\?pool\=1
Running 30s test @ http://localhost:3000/api/v1/test5?pool=1
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   857.51ms   62.36ms 973.93ms   97.39%
    Req/Sec     6.68      3.03    10.00     54.34%
  Latency Distribution
     50%  865.51ms
     75%  868.25ms
     90%  871.34ms
     99%  876.28ms
  345 requests in 30.09s, 221.35KB read
Requests/sec:     11.47
Transfer/sec:      7.36KB

# два пула
$ wrk -t2 -c10 -d30s --latency  http://localhost:3000/api/v1/test5
Running 30s test @ http://localhost:3000/api/v1/test5
  2 threads and 10 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   861.79ms   71.23ms   1.20s    94.19%
    Req/Sec     9.13      5.87    20.00     59.23%
  Latency Distribution
     50%  861.89ms
     75%  868.70ms
     90%  877.96ms
     99%    1.08s
  344 requests in 30.08s, 220.71KB read
Requests/sec:     11.44
Transfer/sec:      7.34KB

Итоги - хуже не стало, но и лучше стать не могло.

Нестабильная ручка - один пул

Следующих эксперимент. Делаем ручку нестабильной. Пусть у second постоянно будет таймаут

def second
  sleep(1.3)
  render json: { success: true, name: __method__ }, status: :ok
end

Пишем lua-скрипт для чтения боди, чтобы точно знать что у нас отвалилось при нестабильной ручке second

-- body.lua
function response(status, headers, body)
  io.write("status: " .. status .. " body: " .. body .. "\n")
end

тестируем через wrk один пул

$ wrk -t2 -c10 -d30s -s body.lua --latency http://localhost:3000/api/v1/test5\?pool\=1 > test1.txt
$ tail -n 11 test1.txt
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.21s     5.27ms   1.23s    80.42%
    Req/Sec    12.31     16.55    40.00     73.85%
  Latency Distribution
     50%    1.21s
     75%    1.22s
     90%    1.22s
     99%    1.23s
  240 requests in 30.08s, 146.58KB read
Requests/sec:      7.98
Transfer/sec:      4.87KB

По итогу latency упирается в потолок, что предсказуемо

Во время запуска wrk можно отправить запросы на ручки second и first и заметить, что во время нагрузки, время ответа у них увеличилось

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

total: 1.406698s
http: 200

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/first
{"success":true,"name":"first"}

total: 0.563120s
http: 200

$ curl -s -w "\n\ntotal: %{time_total}s\nhttp: %{http_code}\n"  http://127.0.0.1:4000/api/v1/services/first
{"success":true,"name":"first"}

total: 0.209376s
http: 200

Итого: latency под таймаут, rps под 7 запросов. Давайте посмотрим на ответы и увидим что отваливается. В файле test1.txt строки типо типо

status: 200 body: {"success":true,"partial":false,"results":{"a1":{"ok":true,"data":{"success":true,"name":"first"}},"a3":{"ok":true,"data":{"success":true,"name":"third"}},"a2":{"ok":true,"data":{"success":true,"name":"second"}}}}
status: 200 body: {"success":true,"partial":true,"results":{"a1":{"ok":false,"error":"deadline_exceeded"},"a3":{"ok":false,"error":"deadline_exceeded"},"a2":{"ok":false,"error":"deadline_exceeded"}}}

Если погрепать, то мы увидим что отваливаются почти все ручки

$ grep '"partial":false' test1.txt| wc -l
  0
# 0 полных ответов

$ grep '"partial":true' test1.txt| wc -l
  240
# 236 неполных ответа

$ grep '"a1":{"ok":false' test1.txt|wc -l
  235
$ grep '"a2":{"ok":false' test1.txt|wc -l
  240
$ grep '"a3":{"ok":false' test1.txt|wc -l
  235

Нестабильная ручка - два пула

Пробуем два пула пул

$ wrk -t2 -c10 -d30s -s body.lua --latency http://localhost:3000/api/v1/test5 > test2.txt

$ tail -n 11 test2.txt
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.21s     5.31ms   1.23s    70.00%
    Req/Sec    14.36     17.72    40.00     68.06%
  Latency Distribution
     50%    1.21s
     75%    1.22s
     90%    1.22s
     99%    1.23s
  240 requests in 30.08s, 151.17KB read
Requests/sec:      7.98
Transfer/sec:      5.03KB

Latency такой же, RPS такой же. Смотрим что отваливается. Если погрепать ответы, то мы к удивлению заметим, что отваливается только долгая ручка.

$ grep '"partial":false' test2.txt| wc -l
  0
# 0 полных ответов

$ grep '"partial":true' test2.txt| wc -l
  240
# 240 неполных ответов


# отваливается только долгая ручка
$ grep '"a1":{"ok":false' test2.txt|wc -l
  0
$ grep '"a2":{"ok":false' test2.txt|wc -l
  240
$ grep '"a3":{"ok":false' test2.txt|wc -l
  0

Ура! Стабильно отваливается только second, что мы и хотели достить. А деградация сервиса second никак не влияет на запросы к first и third. Этого мы и хотели добится тем, что поставили отдельный пул запросов на нестабильную ручку.

Итоги

По сути с один пулом, мы поймали ситуацию, когда блокирующие запросы влияют на всю систему. Когда все исходящие запросы идут в один общий пул, медленный second иногда занимает все слоты, и из-за этого в дедлайн не успевают даже быстрые first, third — они просто стоят в очереди.

Мы разделили пул на FAST/SLOW: slow-запросы могут умирать сколько угодно, но не могут влиять на fast-запросы. Поэтому быстрые ответы остаются стабильными, а медленные превращается в необязательные через partial response.

Выводы

Мы столкнулись с проблемой сервисов агрегаторов - неконтролируемой параллельность исходящих запросов. Мы научились:

ограничивать внешний пул соединений
отлаживать результаты wrk-тестов через lua-скрипты
разделять внешний пул соединений чтобы медленные/недоступные сервисы не аффектили нашу функциональность
реализовывать partial response
поняли, что лучше смотреть логи nginx, а не рельсы, если хотим посмотреть время ответа ближе к реальному у пользователя

На этом всё. Ждите следующие статьи

Параллелизм в ruby 1: создаем потоки

Vladislav Kopylov — Fri, 13 Mar 2026 19:41:58 +0000

Параллелизм в ruby 1: создаем потоки

После 9 лет работы на позиции Ruby-разработчика, я заметил, что нам редко попадаются задачи на параллелизм. К тому же книги на тему "параллелизм в языке N" есть почти про любой язык, но касательно Ruby это ограничивается следующим:

Исторически мы привыкли решать такие задачи на уровне архитектуры. Когда рубист попадает в другую экосистему, то испытывает культурный шок. В связи с этим я хотел бы поставить точки над i в тему тредов и ракторов, как минимум сам для себя; посмотреть какие задачи на параллелизм решаются в других языках, что можно оттуда подчеркнуть и перенести в Ruby. Это будет серия статей, так что наслаждайтесь

Первый эксперимент

Наша первая тема предсказуема, но это база. Представьте, что мы в мире микросервисов и межсервисной коммуникации. У нас есть 3 сторонних сервиса: first, second и third. Каждый из них с какими-то своими данными и своим временем ответа.

В рамках эксперимента мы может симулировать это при помощи одного контроллера на ruby. И мы будем использовать функцию sleep чтобы симулировать нужное нам время ответа:

module Api
  module V1
    module Services
      class ServicesController < ::ApplicationController
        SLEEP_MIN = 0.1
        SLEEP_MAX = 0.2

        def first
          sleep(SLEEP_MIN)
          render json: { success: true, name: __method__ }, status: :ok
        end

        def second
          sleep(SLEEP_MAX)
          render json: { success: true, name: __method__ }, status: :ok
        end

        def third
          sleep(SLEEP_MIN)
          render json: { success: true, name: __method__ }, status: :ok
        end
      end
    end
  end
end

Мы можем поднять приложении на 4000 порту с конфигурацией пумы в 1 воркер и 5 тредов. Запустим 1 воркер чтобы процесс использовал всего одно ядро CPU и 5 тредов чтобы ограничить его мощность

RAILS_ENV=production RAILS_LOG_LEVEL=debug RAILS_MAX_THREADS=5 rails s -p 4000

Наши ручки:

http://127.0.0.1:4000/api/v1/services/first отвечает от 100ms
http://127.0.0.1:4000/api/v1/services/second отвечает от 200ms
http://127.0.0.1:4000/api/v1/services/third отвечает от 100ms

curl http://127.0.0.1:4000/api/v1/services/first
{"success":true,"name":"first"}

curl http://127.0.0.1:4000/api/v1/services/second
{"success":true,"name":"second"}

curl http://127.0.0.1:4000/api/v1/services/third
{"success":true,"name":"third"}

Получается что first и third могут держать 10 запросов на секунду * 5 тредов = до 50 rps

wrk -t1 -c5 -d30s --latency http://127.0.0.1:4000/api/v1/services/first
Running 30s test @ http://127.0.0.1:4000/api/v1/services/first
  1 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   109.54ms    2.82ms 119.14ms   68.27%
    Req/Sec    46.00      9.36    50.00     90.75%
  Latency Distribution
     50%  109.44ms
     75%  111.35ms
     90%  113.28ms
     99%  116.45ms
  1371 requests in 30.06s, 634.62KB read
Requests/sec:     45.62
Transfer/sec:     21.12KB

$ wrk -t1 -c5 -d30s --latency http://127.0.0.1:4000/api/v1/services/third
Running 30s test @ http://127.0.0.1:4000/api/v1/services/third
  1 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   109.63ms    3.58ms 125.36ms   69.28%
    Req/Sec    45.82      9.03    50.00     88.74%
  Latency Distribution
     50%  109.01ms
     75%  111.87ms
     90%  114.48ms
     99%  120.07ms
  1367 requests in 30.06s, 632.77KB read
Requests/sec:     45.48
Transfer/sec:     21.05KB

second может держать 5 запросов на секунду * 5 тредов = до 25 rps

wrk -t1 -c5 -d30s --latency http://127.0.0.1:4000/api/v1/services/second
Running 30s test @ http://127.0.0.1:4000/api/v1/services/second
  1 threads and 5 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   210.98ms    3.92ms 235.80ms   75.49%
    Req/Sec    23.17      5.44    40.00     78.70%
  Latency Distribution
     50%  210.54ms
     75%  212.86ms
     90%  215.47ms
     99%  226.10ms
  710 requests in 30.08s, 329.35KB read
Requests/sec:     23.60
Transfer/sec:     10.95KB

Приложение агрегатор

Теперь задача следующая: нам нужно написать сервис-агрегатор, которое обращается ко всем трем ручкам и собирает результат. Так как у нас мир микровервисов, то это нормальная ситуация что мы стучимся в 3 разные ручки

module Api
  module V1
    class BaseController < ::ApplicationController
      def test1
        first = JSON.parse(Faraday.get('http://localhost:4000/api/v1/services/first').body)
        second = JSON.parse(Faraday.get('http://localhost:4000/api/v1/services/second').body)
        third = JSON.parse(Faraday.get('http://localhost:4000/api/v1/services/third').body)

        render json: { success: true, first:, second:, third: }, status: :ok
      end
    end
  end
end

Запускаем агрегатор с одним тредом чтобы показать нагрузку с одного потока

RAILS_ENV=production RAILS_LOG_LEVEL=debug RAILS_MAX_THREADS=1 bin/rails s -P aggregator

Видим, что ручка агрегирует результат

$ curl  http://localhost:3000/api/v1/test1
{"success":true,"first":{"success":true,"name":"first"},"second":{"success":true,"name":"second"},"third":{"success":true,"name":"third"}}%

Рассчитаем кол-во rps - 100+200+100 = 400ms * 1 тред = до 2.5 rps

$ wrk -t1 -c1 -d20s --latency http://localhost:3000/api/v1/test1
Running 20s test @ http://localhost:3000/api/v1/test1
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   441.46ms    4.11ms 450.74ms   68.89%
    Req/Sec     1.62      0.49     2.00     62.22%
  Latency Distribution
     50%  441.04ms
     75%  444.15ms
     90%  447.51ms
     99%  450.74ms
  45 requests in 20.09s, 25.58KB read
Requests/sec:      2.24
Transfer/sec:      1.27KB

Добавляем thread

Отправлять так запросы в один поток - плохая идея. Агрегатор тратит время на I/O. Лучше распараллелить. В Ruby для этого есть треды, будем их использовать

URLS = {
  a1:  'http://localhost:4000/api/v1/services/first',
  a2: 'http://localhost:4000/api/v1/services/second',
  a3:  'http://localhost:4000/api/v1/services/third',
}

def test2
  threads = URLS.transform_values do |url|
    Thread.new { JSON.parse(Faraday.get(url).body) }
  end
  results = threads.transform_values(&:value)

  render json: { success: true, **results }, status: :ok
end

Проверяем, что ручка работает и дает тот же результат

$ curl  http://localhost:3000/api/v1/test2
{"success":true,"a1":{"success":true,"name":"first"},"a2":{"success":true,"name":"second"},"a3":{"success":true,"name":"third"}}

Рассчитаем кол-во rps. Можно сказать, что мы упираемся в самую долгую ручку second, которая отвечает по 200 ms. Значит, у нас будет до 5 rps

$ wrk -t1 -c1 -d20s --latency http://localhost:3000/api/v1/test2
Running 20s test @ http://localhost:3000/api/v1/test2
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   222.53ms    5.31ms 244.38ms   77.78%
    Req/Sec     3.84      0.50     5.00     73.33%
  Latency Distribution
     50%  221.15ms
     75%  224.82ms
     90%  231.25ms
     99%  244.38ms
  90 requests in 20.08s, 50.27KB read
Requests/sec:      4.48
Transfer/sec:      2.50KB

Дальше мы можем масштабироватся по кол-ву воркеров. Поставим 3 воркера

RAILS_ENV=production RAILS_LOG_LEVEL=debug RAILS_MAX_THREADS=3 bin/rails s -P aggregator

Рассчитаем кол-во rps. 200 ms (самая долгая ручка) *3 = в теории до 15 rps

# ничего не даст тк один поток. 2 коннекшена просто ждут
$ wrk -t1 -c1 -d20s --latency http://localhost:3000/api/v1/test2
Running 20s test @ http://localhost:3000/api/v1/test2
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   220.56ms    7.56ms 248.08ms   73.63%
    Req/Sec     3.88      0.49     5.00     74.73%
  Latency Distribution
     50%  219.16ms
     75%  224.84ms
     90%  230.87ms
     99%  248.08ms
  91 requests in 20.08s, 50.83KB read
Requests/sec:      4.53
Transfer/sec:      2.53KB

# увеличиваем кол-во коннекшенов по кол-ву пумовских тредов
$ wrk -t1 -c3 -d20s --latency http://localhost:3000/api/v1/test2
Running 20s test @ http://localhost:3000/api/v1/test2
  1 threads and 3 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   261.16ms   49.19ms 335.77ms   63.32%
    Req/Sec    11.49      4.42    20.00     73.96%
  Latency Distribution
     50%  223.98ms
     75%  317.08ms
     90%  323.51ms
     99%  329.81ms
  229 requests in 20.08s, 127.92KB read
Requests/sec:     11.41
Transfer/sec:      6.37KB

Данных механизм позволяет не тратить время на ожидание I/O и, пока один thread что-то ждет, ruby переключается на другой thread. Они хорошо подходят под кейсы, когда у вас есть независимые друг от друга запросы.

Thread можно использовать и в запросах в базу. Например, вы пишите CMS и у вас есть ручка, которая отдает статьи по фильтру и выводит кол-во всего статей по данному фильтру, чтобы фронт отрисовал постраничную навигацию. В контроллере обычно это выглядит так

def index
  articles = Article.where(filtered_params).limit(limit).offset(offset)
  count = Article.where(filtered_params).count

  render json: { articles:, count: }
end

Так как это два независимых друг от друга запроса, то при условии что они медленные, нам может помочь thread:

def index
  results = {}
  threads = []
  threads << Thread.new do
    results[:articles] = Article.where(filtered_params).limit(limit).offset(offset)
  end
  threads << Thread.new do
    results[:count] = Article.where(filtered_params).count
  end
  threads.map(&:value)

  render json: results
end

Итоги

Итак, мы научились:

Высчитывать rps. Поняли что это упирается в математику latency × concurrency
Отправлять запросы параллельно

И мы поняли, что для параллелизации в Ruby есть thread. Они являются хорошим инструментов если ваш код где-то ждет и тратит время на I/O. Распараллелить http-запросы, запросы в базу или запросы к OS - типичные примеры где могут пригодится threads

Заменят ли нас нейросети?

Vladislav Kopylov — Sat, 17 May 2025 13:38:57 +0000

И чем ближе мы оказываемся к центру города, тем плотнее нас окружают волшебные сады диковинных технологических растений.
Механизм, Эрнст Юнгер

Такие машины, как генеративные нейросети, gpt-модели стали частью нашей реальности, как когда-то электричество и интернет. Их громко называют "искусственным интеллектом", про них пишутся статьи и в этот момент, когда слова текут из машин быстрее, чем из человеческих уст, человек впервые ощутил, что он больше не уникальный обладатель языка. Для кого-то этот вопрос стал источником страха, как для луддитов в Англии, которые со страхом смотрели на прядильные станки. Работники, чья работа - создание текста, читают новости о сокращениях, связывают эти события с появлением gpt-моделей и задаются вопросом: что буду делать я, когда эта система, не знающая усталости, будет еще умнее?

К сожалению, нейросети - это не станок, видимый, шумящий, стоящий у нас перед глазами в мануфактуре, мы видим только его интерфейс, это дает ему ореол таинственности. Чтобы разобраться в обоснованности этих мыслей, стоит внимательно изучить сам объект этих страхов

Если посмотреть на эти системы как на организм в разрезе, то глубоко внутри мы обнаружим не искусственные мозги, а нечто иное - статистику. Очень сложный алгоритм предугадывания следующего слова в предложении. Вокруг него множество остальных нейросетей - надстройки, добавляющие ему понимание контекста, связанности текста и прочее. Перед нами чрезвычайно сложный инструмент предугадывания слова, с самой ранней версией которого мы уже знакомы, когда набирали другу sms. Поэтому меня всегда удивляют промпты в стиле "проанализируй данные за последние X лет в сфере Y, проведи исследование Z и дай мне результат A", потому что машине приписывают функции аналитика, исследователя, философа. Это не собеседник, эта машина, которая не думает перед тем как ответить на вопрос, тем более делать сложный анализ. Она только выдает статистически и стилистически похожий на правду ответ

Чтобы этот механизм запустился и заработал, нужно загрузить в систему колоссальный объем данных - современные gpt-модели требуют сотни гигабайт текстовой информации. Эти данные берутся из сети интернет. Утверждение о том, что в систему загружают всё, что когда-либо было написано и выложено в сеть - лукавое упрощение. Машина обрабатывает данные только из открытых источников и тексты под public domain, которые становятся доступны через 70 лет после смерти автора или публикации. То есть кроме оцифрованной классической литературы, он читает много интернет контента сгенеренного самими пользователями: обзоры, ревью, новости, рерайты и переписанные десятки раз тексты - это продукты работы "среднего" пользователя

Факт: значительная часть качественной профессиональной информации не в открытом доступе. Это невидимая зона для gpt. Она находится в библиотеках, архивах, закрытых форумах, в современных книгах, защищенных авторским правом. Это книги, журналы, чертежи, изображения в высоком разрешении, изображения научного оборудования, аудиозаписи с/без транскрибации, контент ТВ и онлайн-кинотеатров, коммерческие базы данных и справочники, дневниковые архивные документы. GPT-продукты не имеют доступа к этим данным, а это очень ценные уникальные знания

О проблеме оцифровки важной, уникальной, профессиональной информации мало кто задумывается. О доступе к защищенным данным ломают головы разработчики gpt-системы. Эти инструменты не читают никакие современные книги, только отзывы на них и обзоры. Можно попросить gpt дать вам краткую выжимку из последней книги писателя N. Это будет компиляция на основе журнальной статьи и обзоров на нее, но не на основе самого произведения. Система производит ощущение осведомленности не имея доступа к оригиналу. Если выясняется, что в обучающую выборку попали защищённые авторским правом тексты, возбуждаются судебные дела

Существуют профессиональные сферы, где нейросети до сих пор не могут быть применены из-за недостатка больших массивов данных для тренировки. Например, переводы хеттских клинописных табличек и текстов на других мёртвых языках. В этой области много непереведенных данных, мало специалистов и нет накопленных гигабайт параллельных текстов, для полноценного обучения нейросетей. Здесь вопрос о применении нейросетей не решен, а до идеи замены специалистов очень далеко

Доступ к качественной профессиональной информации ограничен и эта информация очень медленно наполняет сеть интернет. Количество контента производимый средним пользователем все больше и больше, но "интеллект" этого среднего пользователя деградирует. Обилие информации парадоксально снижает интеллектуальную плотность среды. Это особенно остро проявилось, когда появились новости, что в сети стали появляется данные сгенеренные нейросетями, из-за чего сами нейросети качественно поглупели. Контроль и фильтрация этих массивов данных становится всё более трудной задачей, из-за чего системы сталкиваются с проблемой "мусор на входе - мусор на выходе" (GIGO)

В этом кратком экскурсе мы подошли к проблеме интеллектуальности самой системы и к проблеме информации, на основе которой она обучается. Кто сумеет отфильтровать только качественный контент из сети интернет и приобрести доступ к закрытой профессиональной информации - сможет создать более интеллектуальный механизм. Это фундаментальные проблемы, заметные извне тем, кто наблюдает за системами, а не создаёт их изнутри. О масштабах технических и юридических ограничений, скрытых под NDA, мы можем только догадываться

Каков ответ на главный вопрос: заменят ли нас нейросети? Кратко - нет, не в ближайшей перспективе. Gpt-системы уверенно работают в пределах стандартных, повторяющихся задач. Обратится к ней быстрее чем ввести запрос в поисковик, перейти на очередной сайт и прочитать ответы - ты сразу получаешь одну итоговую компиляцию в виде ответа

Сами форматы её ответов тоже ограничены - это замечал каждый, кто просил систему создать нечто более сложное, чем типовой ответ: рассказ, книгу, картину с кучей деталей и прочее. Тем, кто практиковал vibe coding, знакомо чувство когда машина глупеет на ходу, и процесс превращается в неприятный vibe debugging. У каждой технологии есть предел полезности и я считаю, что даже если они сильно улучшатся в ближайшее время, то останутся на уровне полезного помощника по рабочим задачам

Новый виток в развитии Gpt-систем возможен, если библиотеки, архивы, начнут публиковать свои оцифрованные работы и запускать свои gpt-решения. Маловероятно, что такие учреждения передадут свои данные крупным IT-компаниям. Скорее, они предпочтут разрабатывать решения под себя — возможно, с участием больших игроков, но не под их полным контролем. Идея одного всезнающего Gpt-продукта выглядит всё менее реалистичной. Создание универсальной модели потребует колоссальных ресурсов на фильтрацию, структурирование и правовую очистку контента. Вместо этого мы можем получить коллекцию специализированных моделей, каждая из которых будет знать немного, но точно и только в рамках своей области

Для самих инженеров будет что делать так как эти самые gpt-системы кто-то должен внедрять в действующие корпоративные продукты. Интеграция с ними и написание ai-агентов - новая маленькая ниша, которая уже появилась. Например, есть успешные кейсы внедрения gpt-систем в чаты поддержки пользователей. Если в будущем будет больше доступных фреймворков для настройки своих gpt-систем, то стоит задуматься о смене роли инженера - не как создателя кода, а как оркестратора этих систем

Мое мнение - мы не наблюдаем рождение нового разума. Мы наблюдаем рождение нового инструмента, со своими возможностями и ограничениями

Why I love Ruby

Vladislav Kopylov — Mon, 04 Mar 2024 17:09:25 +0000

I'm a back-end developer with over 8 years of coding experience. As a backend developer, I use lots of different languages to do my stuff, so I've tried a lot of them. I've done a lot of research and decided to focus my efforts on Ruby. This essay is about why I like using Ruby for work, and why it's still relevant in 2023.

1 The Reason for the creation

I start the discussion about a programming language by talking about its history. A lot of programming languages have been created for a practical purpose. For instance, C was made to be a more abstract tool than assembly code. PHP was created as a way to quickly make personal websites using C macroses. Python was developed as a simple tool for system administrator tool, replacing Bash/C scripts for the Amoeba operating system. Some languages were created specifically for some runtime environment.

In Japan, Yukihiro Matsumoto, a programmer with lots of experience in different languages, was searching for a language that suited well. He wanted to spend 8-10 hours per day comfortably coding. After not finding the perfect language among existing ones, he decided to make his own - a language that he would find comfortable and enjoyable to work with. His goal was to create a "true object-oriented language". The first version of Ruby came out in 1995, and now let's take a look at the pros and cons of this language.

2 Strengths of the technology

2.1 Syntax

In order to achieve his goal, Matz has paid close attention to the syntax and object structure. Ruby inherited the object model from Smalltalk 80. which added scripting capabilities and advanced regular expression support from Perl. As a result, Ruby became a strict object-oriented language where everything is an object with methods. Ruby's syntax offers a lot of flexibility, emphasizing syntactic sugar. There are many features such as function calls without parentheses, "code blocks" (similar to anonymous functions that can be passed to any method), and metaprogramming (code that writes code). The code in Ruby is easy to read like English text.

Ruby is very powerful with its syntax, but it can be a bit harder for newcomers, unlike languages with simpler syntax such as Python. Ruby isn't just simple and straightforward like Python or Golang (where if you want to do something, you usually just have one way to do it). For a new Ruby developers, the syntax can feel a bit confusing. For example, there are many methods that basically do the same thing, just with different names - they're called 'aliases' (filter and select, exit and quit do the same. They are here only for convenience.).

There are also some methods that do the same things but with slight different behavior (like each and each_with_index). But despite this, Ruby allows you to overload operators; so you can declare how unary operators work for your classes (this feature is not available in many languages). Also, Matz done a lot of work to make error messages easier for developers to understand. If you get an exception, it won't be a super-long backtrace like you get in Erlang or Java. It won't even be a truncated one like you get in NodeJS (default is 10).

Thanks to those cool features, the language has caught the attention of people all over the world.

2.2 Domain-Specific Language (DSL)

Ruby has a lot of syntactic sugar with features: function calls without parentheses, "code blocks", etc. It gave us the capability to create its own little language for a specific domain (DSL). When building a modern app in Ruby, programmers don't write code in pure Ruby. They use small task-specific dialects for things like testing, routes declaration or writing database migration scripts. It simplifies the code, provides a high level of abstraction and the code reads like English text. As a result, creating a program in Ruby, you typically need about 3-4 times less code than in Java or Python.

When I saw a Ruby code for the fist time, I was amazed by its conciseness. Having experience in C, C++ and PHP, I was considering Ruby like LEGO bricks. The fact that so much can be done with so little code really reminded me of the jQuery motto 'write less, do more,' and it inspired me to learn Ruby deeper.

2.3 Web development

Ruby is a general-purpose language. You can use it for all sorts of things, from writing system administration scripts to program electronics. Ruby has evolved the most as a web development tool thanks to the RubyOnRails framework.

In 2005, David Heinemeier Hansson (DHH), an experienced web developer, posted a video on YouTube about to make a blog in just 15 minutes using RubyOnRails (video). This presentation of the RoR framework was a revolution for its time. Rails quickly gained popularity in contrast to the development speed of other stacks. In the same year, Java ex-developer Bruce Tate released the book Beyond Java, discussing the downsides of Java and highlighting RoR as a big thing in IT. The peak of Ruby's popularity in the web domain lasted from 2007 to 2013. This peak gave rise to an extensive ecosystem of production-ready solutions and libraries for web programming and beyond.

The RoR is an example in the tech world when the tool is highly opinionated. It means that using this technology, it dictates you the project structure, where different parts of the application should be located, how components should be named and more. The framework has its own doctrine. This approach is great because it means you don't have to think about all the configurations for your app. But it also has its downsides, which I'll talk about later.

RoR is a still a full-stack framework that lets you quickly set up a web service from scratch with base tools for building the user interface (UI). Some people say that programming in Ruby is on average 30-40% faster than in other languages. Moreover, many Ruby developers are full-stack developers, it reduces costs for businesses. The speed of development doesn't compromise quality. The time saved can be invested in refactoring, updating libraries or looking for better architecture abstractions instead. In reality, developers often have lack of time to write code with high quality.

Ruby has become the perfect tool for testing business ideas. Although it's slow, people often overlook its real strength - the speed at which it can create new app/feature. Since a business needs to adapt quickly to changes in order to survive, Ruby allows you to adapt your app to new tasks and changes quickly. That's why so many Y Combinator startups are launched using Ruby on Rails.

2.4 Standardization

The core of the Ruby ecosystem focuses on the single framework (RoR). It gives us a big amount of tools for it. For example: test writing is standardized, the library for web interfaces is standardized too (Rack). In the infrastructure level, the application server doesn't care whether it's a Rails application or another Ruby web-framework. Code style is also standardized by rubocop, so a new developer won't get confused about the code style. This is similar to Python and Go, but in some languages you need to choose from N options). Many third-party libraries have already been adapted for Rails. This reduces the time it takes to integrate code into the app. There aren't any situations where you have to deal with dependency conflicts or spend time configuring external libraries. That means we can hire a new Ruby dev who can easily understand the app. The devs already know the file structure, namespacing, etc. On the negative side, sometimes people get bored with all the apps looking the same. But there are other, less popular frameworks out there.

2.5 Knowledge Base on Application Development

Over the years, the community has collected a huge knowledge base about how to build web apps. It's because apps like Cookpad, GitHub, GitLab, Shopify, Basecamp, and Stripe (among others) are all written in Ruby. The community has gained expertise in building and maintaining monoliths (big apps) that can easily scale in the future and how to maintain them long-term.

The Rails community promotes the concept of the majestic monolith. We've figured out a way to write these big apps without the problems that come with them. We're using architecture namespaces to make sure everything is organized and there's no need to rewrite everything into microservices later. This way, we can avoid problems like having a distributed monolith or having to write a bunch of schemas to describe how microservices talk to each other and track requests. If you want to learn more, you can attend community meetings or conferences or read dev's blogs.

The technology also follows all security concerns. Ruby is well-suited for applications that handle personal data, such as financial platforms and marketplaces. The ecosystem follows Security Development Lifecycle to control vulnerabilities also there are solutions for the license checking. Rails 7 includes built-in support for encrypting database data. For this reason, fintech products are also launched on Ruby. In this case, the situation is close to Java and the C languages.

2.6 A tool to solve business problems

When you are coding in Ruby, you don't often worry about things that your colleagues using other programming languages keep in mind. You don't need worry about type declarations, memory usage and etc. You can just focus on the actual problems you're trying to solve. Plus, routine tasks (routing, database structure changes, tests etc.) aren't programmed, but they are described by DSL. That's why it's so great to use Ruby for creating new business features. 8 out of 10 developers are involved in business automation or solving business tasks by the code. RoR guides the developers on how to do it and dictates the structure, allowing the developers to focus on solving the actual business problem, writing code specifically for it, rather than "struggling" with the framework.

However, I want to add that if you're working on atypical tasks, you might find yourself "struggling" with the framework or dealing with legacy issues, like on other languages. Fortunately, in RoR, these limits are pretty wide, so you rarely step outside them, especially if you have a lot of programming experience.

3 Technology Weaknesses

Now, let's discuss the weaknesses of the technology or the aspects it's criticized for.

3.1 Application Performance

Every developer has heard that Ruby is kinda slow, but actually, a lot of languages are considered as "slow". The execution speed of a computer program depends on memory management features. It's a feature of all technologies where memory management is delegated to a virtual machine (VM). For more details, you can watch Grigory Petrov's video Why is Ruby slow? (rus), based on which I wrote a short article.

For many developers, all languages that are labeled as "interpreted" (or scripting) are considered as slow because the interpreter reads the program's source code line by line and executes it. However in 2023, most modern "interpreted" languages arn't really interpreted. Languages like Ruby and Python are compiled into bytecode and executed in a VM. In Ruby since version 1.9 (2011), the interpreter precompiles Ruby into bytecode before execution. With Ruby 2.6 (2018), Just-In-Time compiler (JIT) was introduced, it compiles frequently used instructions into binary code (similar to nodeJS). This approach significantly speed up mathematical calculations by tens of times, bit it struggles to speed up complex projects. Matz paid the price for it because he prioritized on large and diverse syntax feature not speed.

Also in the core of Ruby there is Global Interpreter Lock mechanism (GIL). It slows down program execution as it needs to pause the execution to clean up memory. This is inherited from the time when computers had single-core processors. Although the language has evolved, now Ruby has the Global Virtual Machine Lock (Global VM Lock) inside. Fortunately, technology continues to evolve. In places where the Global VM Lock causes a problem, developers can use features like Fiber, Ractor and others. If your goal is to write a speedy "number calculator" (a script for matrix multiplication, machine learning (ML) or rendering calculations), it's better to replace Ruby with languages where memory management management is delegated to a developer. That's why Ruby isn't the best choice for ML. However, in web development significant portions of time is spent on I/O (waiting for responses from the database or HTTP connections). For these cases your can use Threads where it's critical. For example, Rails 7 introduces parallel execution of database queries with load_async.

In 2019 Basecamp (the main developer of RoR) published an article saying that only 15% of their operating budget is spent actually running Ruby code. So, if you write your app and configure it well, you won't really notice any slowdowns. Even if they spend a lof of resources making the language twice as fast, that won't actually reduce their company costs by much.

The speed of code execution isn't critical for every application. You will notice slowdowns when your application processes hundred requests a second. Most developers don't face the same load in the early stages of creating an application/product. If your MVP starts with less than hundred requests that's quite good. If it's more, RoR can handle it because the application is scalable by increasing amount of processes and threads.

In computer science, there are some areas where speed is crucial, like parsing XML or working with encryption. For these tasks, Ruby works well because the language allows to write native extensions in C++. Popular libraries for these things are written in C++ and Ruby just provides only a wrapper/interface. The similar situation happens in Python with machine learning. Python code doesn't do matrix multiplication, it only manages the data flow. All mathematical operations are performed by C++ extensions. The Python community has really worked hard to make that happen.

3.2 Other Usage Areas

Historically, Ruby has been mainly used for web applications. If you need ML or machine vision, the Python's ecosystem is much advanced. For data analysis R/Python are best suited. But that doesn't mean you can't use Ruby for simple data calculations. Also there still areas where one technology dominates by historical factors: frontend, mobile development, etc. In reality, Ruby is not limited for the web. Check out how it's used in Japan, where there's a massive Ruby community. For them Ruby is more than just Rails. They use it to programming controllers (with mruby), as a scripting language for other systems, in search engines and so on. If you wish talks about Ruby, not just Rails, feel free to explore RubyKaigi.

Ruby is actively used in infrastructure tasks. The popular software for installing applications and packages on macOS HomeBrew is written in Ruby, which is why Ruby pre-installed on macOS. Additionally, if you look at sysadmin job listings, experience with Ruby is often among the requirements. There are also solutions/libraries for other platforms, such as gamedev and frontend. While they might not be very popular, you can explore and play with them if you're interested.

3.3 Type Annotations

Languages like Javascript and Python have already had this, but what about Ruby? For documentation there is Yard, but these annotations are only at the documentation level. For writing and checking types, there is a tool called Sorbet from Stripe. In Ruby 3.0 native type annotations (RBS) have been introduced, but they are written in separate files (similar to C and TypeScript). Types are kept in separate files because Matz believes that developers should focus on business features rather than writing types. He is confident that in nearest future, programming languages will move away from manually writing types towards tools for automatically generating signatures. Work in this direction has started with tools like TypeProf.

3.4 Learning Curve

Ruby learning curve is higher to compare to other languages. The reason is that Ruby's syntax and capabilities can be a bit overwhelming for beginners, so a lot of developers start with Python or Go instead. After gaining initial experience, the most developers tend to explore other languages and explore the capabilities of different technologies. Many Ruby programmers are already experienced in programming before they embrace Ruby. Thankfully for newcomers, Rubocop guarantees a unified coding standard to writing code correctly and with best practices.

4 Hiring

Thanks to the standardization that was talking about earlier, people who come to your project are already familiar with the technologies, significantly reducing the search time. This is important for hiring a new team member. In the onboarding, new developers have to only understand the business domain. With other languages, the situation is different. If we're looking for a Python or PHP developer, we reject some candidates because they've worked with a different framework and during the interview, we need to understand the technologies they are familiar with. Similarly, when hiring a Python developer, we must understand their specialization: backend, automated testing, ML, data science, ETL, etc. That's why having just one Python developer may not be sufficient to launch an application.

In contrast, most RoR developers are full-stack specialists who can launch a web application on your own. Some of them can solve frontend tasks, some of them follow the latest technologies such as HTML over websockets. However, compared to Node or Python, there's not as many Ruby devs and they tend to ask for higher pay.

5 Community

I just want to say that there's more to any technology than meets the eye. Sure, there are the people behind it, and Ruby is known for its amazing community. The community isn't big as in some other languages due to a smaller amount of developer (though history has examples where the core of an ecosystem was created by just one person), it is influential in the open-source world. Projects like GitHub has been released to thanks to the Ruby community. The fundamental principle of the Ruby community is sharing code and ideas, therefore RoR has the highest number of contributors compared to other technologies. Perhaps only the frontend community has a similar obsession for open source.

The community follows Matz's idea that Ruby was created for comfort and fun. How else would you explain methods in RoR arrays like second, third, second_to_last, third_to_last, and suddenly forty_two? Moreover, when Ruby developers switch into other languages, they often bring ideas from the Ruby world. For example, dry-python and pyenv were influenced by concepts from Ruby. The Ruby ecosystem has inspired other languages; for instance, RoR inspired PHP developers to create Laravel, and Rspec inspired JavaScript developers to build libraries like mocha, jasmine, and Chai.

Ruby's community was fortunate to create a canonical, convenient, and high-quality dependency manager, Bundler, in 2009. It's a unified, deterministic dependency installer with a lock file, support for multi-environments, and the ability to install dependencies directly from GitHub. Features that ecosystems like Go and NodeJS can't boast about. Of course, Bundler had its problems in the early years, such as speed issues, but they were successfully overcome. Bundler became the prototype for tools like yarn in JavaScript, cargo in Rust, and composer in PHP.

Ruby's ecosystem used to inspire others, nowadays the trend has shifted. Now Ruby adopts features from other languages. It has received pattern matching, similar to Elixir and Erlang; the transpiler RubyNext (as Babel in JS), allowing the use of new language features on previous Ruby versions, etc. Some solutions for the frontend are inspired by RubyOnRails, for instance: sockpuppet for Django is an implementation of stimulus-reflex from Rails.

The community continues to expand and organize significant conferences worldwide, such as RubyKaigi (Japan), RubyRussia (Russia), Euruko (Europe), RailsConf/RubyConf (USA) and more.

6 Relevance of the Technology

From 2013 to 2015, the language and framework was super popular. But since 2016, But since 2016, people have been saying that "Ruby is dead". That's just not true, though, because every technology goes through the same hype cycle. Each technology experiences a the peak of high expectations and people believe it's outdated, but, in reality, the technology just enters the plateau of productivity. This stage indicates that the technology is mature enough for use in production. Java, for example, isn't dead since 2005, and it's still used in production.

Essentially, it's rare for a technology to die, especially in open source. After the the years of using, a lot of application has been built and each of it requires ongoing support and development. How else can we explain that Fortran is in 16th place in the TIOBE ranking as of 2023? Moreover, how can we consider the actual relevance of technologies? To count the number of questions on Stack Overflow? This indicates the number of beginner developers learning. To count stars or the number of projects on GitHub? But GitHub is like a warehouse of building materials, and in some communities, it's not common to click on the star in GitHub. In bloody enterprise industries, libraries are not often publicly published. Job listings on websites? This indicates a shortage of specialists in this area at the moment. Even TIOBE itself is calculated based on mentions in 25 search engines. Therefore, determining actual relevance is indeed complex.

Conclusion

Ruby was originally designed to be the most user-friendly language for development and it has not changed its core priority. It has launched a rich, stable ecosystem with diverse solutions for a wide range of tasks. It's general-purpose programming language with great full-stack tools in web development. The community has created large base how to build production ready applications. The language has some "weaker" points, but you can overcome them if you understand how and why they came about.The community continues to evolve the language and the tools around it, observing and adopting features from other languages, making Ruby a relevant tool. That's exactly why it suits my needs perfectly after all these years.

Additionally, I agree with Grigory Petrov's words that the Ruby language is an ideal choice for someone if:

They know they enjoy programming and they want to make the process of writing code to be maximally enjoyable.
Their area of expertise is in helping businesses, not gamedev, not frontend, not code for physical devices, not code for scientific calculations, not landing pages. Ruby and its ecosystem are well-suited for solving business problems using web applications, integration scripts and more.

If these are your specific needs, then choosing on Ruby is a good decision!

I ♥️ Ruby

How to run CRON with Docker in alpine

Vladislav Kopylov — Fri, 26 Jan 2024 17:57:04 +0000

In my job, we are using alpine docker images for each application. In order to implement new feature we have installed CRON in a docker image. We have noticed that CRON does not work. In logs we saw the error:

crond: can't set groups: Operation not permitted

It was unusual bug. I have found that in alpine CRON must be running as the root privilege. It's harmful for security concerns. In order to run CRON as the normal user privilege there are two solutions:

Using geekidea/alpine-cron docker images
Choose another linux distributive

The choice is yours...

Почему я программирую на Ruby

Vladislav Kopylov — Thu, 19 Oct 2023 19:44:45 +0000

Я - backend-разработчик и на 2023 год я программирую около 8 лет. На backend'е платформа не навязывает какой-то один язык для разработки, поэтому за это время я получил большой опыт в программировании, попробовал многие языки, но остановился на Ruby. В данном эссе я хочу сформулировать мысли почему я использую Ruby для решения моих рабочий (и не только) задач, какие у него есть плюсы, минусы, особенности и почему в 2023 он все еще актуальный язык.

1 Причина создания

Начинать рассказ об языке стоит с его истории. Создание языков программирования часто носит утилитарный характер. Например: Си создавался чтобы получить инструмент выше уровня абстракции чем ассемблер. PHP создавался как макросы над C чтобы быстро создать личную веб-страницу. Python создавался как простой и надежный инструмент системного администрирования, чтобы заменить скрипты на bash, Си для ОС Amoeba. А какие-то языки создавались под определенную среду выполнения.

В далекой Японии Юкихиро Мацумото, который имел большой опыт в программировании и знал немало языков, искал инструмент под себя. Искал язык чтобы с комфортом, насколько это возможно, программировать на нем по 8-10 часов. Во всех языках которые были доступны на тот момент были свои минусы и он решил написать свое - язык на котором комфортно, приятно работать. Он хотел создать «настоящий объектно-ориентированный язык». Так и вышла первая версия Ruby в 1995 году. Теперь подробнее про сильные и слабые стороны этой технологии.

2 Сильные стороны технологии

2.1 Синтаксис

Для реализации цели Матц уделил много внимания возможностью синтаксиса и структуре объектов. Ruby унаследовал объектную модель от Smalltalk 80 и получил от Perl свою скриптовость и продвинутую поддержку регулярок. Получился строгий объектно-ориентированный язык, в котором все является объектом и методом. В нем много возможностей которые предлагает синтаксис. Упор на синтаксический сахар породил такие фишки как вызовы функций без скобок, "блоки кода" (а-ля анонимная функция которую можно передать в любой метод) и метапрограммирование (код который пишет код). И код на этом языке можно прочитать как текст на английском языке.

Но из-за богатого синтаксиса в Ruby порог входа выше чем в похожих языках, например Python. В Ruby нет только простых конструкций, как в Python или Golang. В этих языках если хочется что-то сделать, то есть один способ реализовать это. Человек пришедший после них в Ruby заметит, что синтаксис переусложнен. Например, много методов которые отличаются только названием "алиасы" (filter и select, exit и quit делают тоже самое и нужны только для удобства). Много методов которые делают похожее, но чуть с другим поведением (each и each_with_index). При этом язык позволяет не только перегружать операторы, а также объявить поведение унарных операторов для своих классов - не во многих языках вы найдете похожее. Для удобства разработки Матц также продумал структуру сообщений об ошибках. Если разработчик что-то сделал не так, то получает не километровый backtrace, как в Erlang или Java, и не урезанный как в nodeJS (по умолчанию 10)

Благодаря таким фичам новый язык заинтересовал других людей по всему миру.

2.2 Domain-Specific Language (DSL)

Упор на синтаксический сахар, вызовы функций без скобок и "блоки кода" создали в языке возможность написать свой маленький язык под узкую предметную область (DSL). Создавая современное приложение на Ruby программист пишет не на чистом Ruby, а использует использует маленькие специфичные диалекты под узкую задачу, например: для тестирования, для объявление роутов, для написания миграций данных в БД и прочее. Это упрощает написание кода под эти задачи. Дает максимальный уровень абстракции и код выглядит как текст на английском языке. Как результат, создавая программу на Ruby нужно в 3-4 раза меньше кода чем в Java или Python.

Когда я впервые увидел код на руби, то удивился его лаконичностью. Я до этого писал на Си, C++ и PHP и смотрел на Ruby как на детский конструктор. Но именно то, что на нем достаточно написать немного, напомнило мне девиз jQuery "write less, do more" и вдохновило изучить Ruby.

2.3 Web development

Из Ruby получился язык общего назначения. На нем можно писать скрипты для администрирования систем, программировать электронику и прочее. Но наибольшее развитие он сделал как веб-технология благодаря фреймворку RubyOnRails.

В 2005 году David Heinemeier Hansson - опытный веб-разработчик, выкладывает на YouTube видео как он создает блог за 15 минут (видео). Эта презентация фреймворка RubyOnRails была революцией для своего времени. Rails резко нарастила популярность на контрасте со скоростью разработки на других стеках в то время. В этом же году опытный джавист Брюс Тейт выпускает книгу Beyond Java о минусах Java и о том, что Ruby и Rails - новое слово в космонавтике. Сам пик популярности Ruby в вебе приходился с 2007 по 2013 год. Этот пик породил огромную экосистему готовых решений, библиотек, для веб-программирования и не только.

Пример RubyOnRails - нетипичная ситуация в мире. Инструмент очень opinionated т.е. использование этой технологии диктует тебе структуру проекта, то какие части приложения где должны находится, как нужно называть компоненты и прочее. Поэтому он имеет свою доктрину. Такой подход позволил меньше задумываться о проблемах конфигурации приложения, но в этом есть плюсы и минусы, о которых поясню дальше.

До сих пор RubyOnRails - fullstack фреймворк. На нем можно быстро поднять какой-нибудь веб-сервис с нуля. По-умолчанию в нем есть инструменты и для написания интерфейса. Говорят, что программирование на Ruby в среднем на 30-40% быстрее чем на других языках. Плюс многие разработчики могут писать на нем бек и фронт (простенький и не очень), что сокращает издержки для бизнеса. Причем скорость разработки не идет в ущерб качеству т.к. освободившиеся время можно потратить на рефакторинг, который постоянно хотят разработчики, а бизнес нет; или на обновления библиотек, обдумывание архитектуры или поиск лучших абстракций. Да и бизнес реалии таковы, что у разработчиков почти всегда не хватает времени или четкости требований, чтобы писать код качественно, строго придерживаться паттернов, делая всё как в учебниках.

Поэтому Ruby оказался идеальным, быстрым и очень эффективным решением для проверки бизнес идей. И сейчас, несмотря на статус-кво что Ruby медленный, люди забывают о его сильной стороне — скорости самой разработки. А при условии что чтобы бизнес выжил он должен быстро приспосабливаться к внешним изменениям, это позволяет быстро адаптировать ваше приложение под новые задачи или изменения ТЗ. Поэтому немалая часть стартапов Y-combinator запускается при помощи RubyOnRails.

2.4 Стандартизация

Основной костяк экосистемы Ruby сформировался вокруг одного фреймворка. Это породило единый пул инструментов. Стандартизировано написание тестов для приложения, поэтому редкий рубист не пишет тесты. Стандартизирована библиотека для веб интерфейса - это Rack. Благодаря нему на уровне IT инфраструктуры, серверу приложения будет все равно что за ним приложение на Rails или на другом Ruby web-фреймворке. Стандартизирован и код-стайл. Поэтому новый разработчик на новом проекте не увидит для себя сюрпризов (по код-стайлу аналогичная ситуация в Python и Go, а в некоторых языка надо выбирать из N вариантов). Многие сторонние библиотеки уже адаптированы под рельсу, это сокращает время на интеграцию кода в приложение. Не будет ситуаций что при добавления сторонней библиотеки приходится разрешать конфликт зависимостей или тратить время на то чтобы объяснить библиотеки как работать внутри этого фреймворка. Такая ситуация привела к тому, что можно нанять нового Ruby разработчика и он достаточно быстро разберется в приложении. Он уже знает структуру папок, особенность работы и загрузки файлов и прочее. Из минусов, некоторым становится скучно, что все приложения одинаковые, но у нас есть и другие фреймворки (менее популярные).

2.5 База знаний по тому как писать приложения

За годы своей популярности и использования, в комьюнити накопилась обширная база по тому как писать веб-приложения. Комьюнити набрало экспертизу как писать монолиты, которые в будущем вырастут и как дальше их поддерживать. Такой опыт действительно есть т.к. такие огромные приложения как Cookpad, GitHub, GitLab, Shopify, BaseCamp, Stripe написаны на Ruby.

Сообщество Rails продвигает концепцию majestic monolith. Чтобы не страдать от разросшегося приложения, собрана методология как писать монолиты, как прочерчивать архитектурные границы внутри монолита. Чтобы потом не переписывать их на микросервисы и позднее дополнительно не страдать от того, что у нас получился распределенный монолит. Или от того, что мы пришли в мир распределенных приложений и надо писать схемы которые описывают как микросервисы общаются между собой и мониторить пути запросов. Сами рельсы предлагают основные концепции по стыковочным точками и сервисным объектом. Про остальные решение можно узнать посетив встречи коммьюнити, конференции или почитав блоги опытных разработчиков.

Также вопросы безопасности не обошли эту технологию стороной. Ruby хорош и для приложений которые собирают личные данные (финансовые платформы, маркетплейсы и прочее). В экосистему внедрен Security Development Lifecycle, для контроля уязвимостей и проверки чистоты лицензий уже есть готовые решения. В Rails 7 есть поддержка шифрования данных БД из коробки. По этой причине финтех-продукты запускаются и на Ruby тоже. Со всем этим Ruby уступает только Java, и языкам семейства Си.

2.6 Инструмент решения бизнес задач

Когда пишешь код на Ruby ты не часто задумываешься о вещах, о которых думаю коллеги использующие другие языки: об объявлении типов, об использовании и очистки памяти и прочего. Обычно тебе не надо заботиться о памяти и об других узких вещах и тратить время чтобы объяснить компьютеру что с ними делать. Плюс рутинные вещи (роутинг, изменения структуры БД, тесты и прочее) не программируются, а описываются при помощи DSL. Поэтому из Ruby получился удобный язык чтобы писать бизнес-логику и внедрять новые фичи. Это как раз это то чем в настоящее время занимаются большинство разработчиков. 8 разработчиков из 10 занимаются бизнес-автоматизацией - решают или упрощают бизнес-задачи при помощи кода. RubyOnRails диктует разработчику как делать и диктует структуру, а разработчик следуя ей решает именно бизнес задачу, пишет код именно под нее, а не "борется" с фреймворком.

Но тут надо добавить что если пишешь что-то нетипичное, то будешь "бороться" с фреймворком или с легаси, как на других языках. Благо в RubyOnRails эти "рамки" достаточно широкие так что выходишь за них редко и уже имея немалый опыт программирования.

3 Слабые стороны технологии

Теперь про слабые стороны технологии или за что его критикуют.

3.1 Скорость работы приложения

Редкий разработчик не слышал что Ruby медленный, но по факту, многие языки "медленные". Скорость исполнения компьютерной программы зависит от особенностей работы с памятью и является одной из особенностей всех технологий где забота о памяти делегируется виртуальной машине. Подробнее об этом можно посмотреть доклад Григория Петрова Почему Ruby медленный? на основе которого я писал небольшую статью.

Для многих разработчиков все языки которые мы называем "интерпретируемые" (или скриптовыми) - медленные т.к. интерпретатор читает исходный код программы строчка за строчкой и выполняет ее. Но по состоянию на 2023 год современные "интерпретируемые" языки уже такими не являются. Тот же Ruby, Python компилируются в байткод и исполняются в виртуальной машине (VM). В Ruby с версии 1.9 (2011 год) интерпретатор прекомпилирует Ruby в байткод перед его выполнением. С Ruby 2.6 (2018) появляется Just-In-Time compiler (JIT), который компилирует часто используемые инструкции в бинарный код (почти как в nodeJS). Какие компиляторы могут ускорить математические вычисления в десятки раз, но не могут ускорить сложный проект из-за особенностей использования памяти в самом языке. Зато при создании таких языков у нас не ограничивается синтаксис, об удобстве которого так заботился Матц, и есть возможности к расширяемости.

Также в основе Ruby лежит механизм Global Interpreter Lock (GIL) из-за которого тормозит выполнение программы т.к. надо останавливать выполнение кода и очистить память. Это надо принять т.к. язык создавался когда на компьютерах были одноядерные процессоры. Конечно язык уже изменился и в данных момент это уже Global Virtual Machine Lock (Global VM Lock), но проблема осталась. Благо развитие технологии не стоит на месте, поэтому в местах приложения где Global VM Lock является проблемой можно использовать такие возможности языка как Fiber, Ractor и прочее. Но все же, если хочется написать быструю "числодробилку" (скрип для перемножения матриц, ML или расчет рендеринга), то лучше взять языки где забота о памяти делегирована разработчику. Поэтому Ruby не нашел себя в ML, но в вебе большая часть времени тратиться на I/O (приложение ждет ответа от БД или от http-соединения), там где это критично можно использовать Thread. Например в Rails 7 уже есть параллельное выполнение запросов в БД load_async.

В 2019 году компания Basecamp (основной разработчик RubyOnRails) выпустила статью, что только 15% операционного бюджета тратится на исполнения Ruby кода. Если хорошо написать и сконфигурировать приложение, то тормозов особо не почувствуешь. Даже если бы они потратили усилия и сделали язык в 2 раза быстрее, то это не сильно уменьшит затраты компании. Так что ускорение исполнения кода не в ТОП-приоритетах.

Не для каждого приложения скорость исполнения кода критична. Вы заметите пробуксовку если ваше приложения начнет обрабатывать сотню запросов в секунду. Редкий разработчик получается такую нагрузку на начальных этапах создания приложения/продукта. Если MVP на старте имеет под сотню запросов - это очень хорошо. Но и с ней RubyOnRails может справится т.к. имеются возможности масштабируемости через увеличение процессов и потоков.

С точки зрения языка, есть сферы где скорость исполнения решает: парсинг XML, работа с шифрованием и прочим. Для таких сфер есть выход т.к. Ruby позволяет встроить расширения на C++. Популярные библиотеки для работы с такими задачами написаны как раз на C++, а на Ruby реализована только оболочка/интерфейс. Точь-в-точ такая же ситуация в Python в сфере ML. Сам код Python не занимается числодроблением или перемножением матриц, а занимается только управлением потоком данных. Там все математические операции совершаются расширениями на C++, а комьюнити Python потратило много времени чтобы ситуация стала такой.

3.2 Остальные сферы использования

Исторически сложилось, что основная сфера использования Ruby - это веб-приложения. Если нужен ML или машинное зрения, то экосистема Python намного богаче. Если нужно подсчитать аналитику, то есть R или Python. Но это не значит что какие-то простенькие данные не получится посчитать на Ruby. Еще есть сферы в которых монополия одной технологии: фронтенд, мобильная разработка и прочее, в них так исторически сложилось. Но по факту Ruby используется не только в вебе. Если интересно, то посмотрите как его используют в родной для него Японии. Там находится огромное ruby-комьюнити и исторически сложилось что Ruby - это не только рельсы. Сфера его использования более широкая, японцы применяют его как обычный скриптовый язык. Они используют его в программировании контроллеров (есть mruby), как скриптовый язык для других систем, в написание поисковых движков и пр. Поэтому, если хотите послушать доклады про Ruby, а не про Rails - добро пожаловать на RubyKaigi.

Еще Ruby активно используется в инфраструктурных задачах. Под macOS на нем написана популярная утилита установки приложений и пакетов HomeBrew из-за которой Ruby появился по-умолчанию в macOS. Плюс в вакансиях сисадминов в требованиях можно увидеть опыт с Ruby. Под Ruby есть решения для других платформ, например: для gamedev и для frontend. Они не очень популярны, но при желании поиграть с ними можно.

3.3 Аннотация типов

Такие языки как Javascript и Python к этому уже дошли, а что с Ruby? Для документации аннотации типов есть yard, но это аннотации только на уровне документации. Для написании и проверки типов есть инструмент Sorbet от Stripe. В Ruby с версии 3.0 появилась нативная аннотация типов (RBS), но они пишутся в отдельных файлах, как в Cи и TypeScript. Типы вынесены в отдельные файлы т.к. создатель языка уверен, что разработчики должны ориентироваться на бизнес-фичах, а не на написании типов. Он уверен что через пару лет языки программирования отойдут от ручного написания типов в сторону инструментов автоматическая генерация сигнатур и работа по этому направлению уже идет - TypeProf.

3.4 Входной порог

В Ruby входной порог выше чем у других языков, поэтому часто Ruby - не первый язык программирования. У синтаксиса богатые возможности, но именно они могут запутать новичка. Поэтому новичкам советуют начать с Python или Go т.к. там все конструкции простые, а после первого опыта человек смотрит какие еще языки есть, что ему не нравится в текущем инструменте и какие возможности дают другие технологии. Собственно, многие Ruby программисты уже имели опыт программирования на других языках прежде чем они пришли к Ruby. Благо линтер Rubocop задает единый стандарт написания и поможет объяснить новичку как писать код правильнее и покажет ему лучшие практики.

4 Особенности найма

Благодаря стандартизации, о которой я писал выше, люди приходят к вам на проект и технологии будут им знакомы, отчего время поиска сильно сокращается. Это удобно когда ищешь нового сотрудника. На начальных этапах новому разработчику необходимо будет понять особенность предметной области в которой работает ваш бизнес, что упрощает онбординг.

С другими языками такое не пройдет. Ищите вы Python или PHP разработчика и уже на этапе составления описании вакансии мы отрезаем часть кандидатов потому что они работали с другим фреймворком. Возьмем Java или PHP разработчика - на собесе надо понять на чем он может писать. Возьмем питониста - надо понять его специальность - backend, автотесты, ML, Data Science, ETL. Поэтому одного разработчика на Python может быть недостаточно для запуска приложения. Большинство RubyOnRails разработчиков - это fullstack специалисты, которые в одиночку могу запустить web-приложение. Кто-то может написать простенький фронт, кто-то следит за технологиями и писал HTML поверх вебсокетов. Но на рынке их меньше чем nodeJS или Python разработчиков и обычно просят они больше.

5 Комьюнити

Хочется добавить что за любой технологией стоят люди, а Ruby славится своим комьюнити. Может быть оно не такое большое как в других языках т.к. разработчиков меньше (но история знает примеры когда костяк экосистемы написал всего один человек), но оно не последнее по влиянию на open source. Благодаря Ruby-комьюнити появились такие проекты как GitHub т.к. сам принцип обмениваться кодом и идеями лежит в основе этого комьюнити. Еще у RubyOnRails больше всего контрибьюторов по сравнению с другими технологиями. Такой же любовью к open source наверно может похвастаться только фронтенд комьюнити.

Само комьюнити продолжает идею Матца что Ruby создавался в первую очередь для комфорта иначе как объяснить что в RubyOnRails есть такие методы у массива как second, third, second_to_last, third_to_last и внезапно forty_two. Плюс, Ruby разработчики, когда уходят в другие языки часто привносят туда идеи, которые они увидели в мире Ruby, например: dry-python и pyenv. Экосистема Ruby была вдохновением для других языков например: RubyOnRails вдохновила PHP разработчиков на Laravel; Rspec вдохновила JS разработчиков на написании библиотек mocha, jasmine и Chai.

При этом Ruby комьюнити повезло что у них в 2009 году получилось написать один каноничный удобный и качественный установщик зависимостей bundler Единый детерминированный установщик зависимостей с lock-файлом, с поддержкой multi-ENVs и с возможностью установки зависимостей сразу с GitHub. Чем не могут похвастаться экосистемы Go и NodeJS. Конечно и у него были свои проблемы в первые годы, например проблемы со скоростью, но и их удалось преодолеть. Bundler стал прообразом таких инструментов как yarn в JS, cargo в Rust и composer в PHP.

Раньше экосистемой Ruby вдохновлялись, но сейчас тренд развернулся на то, что Ruby стал брать что-то от других. У нас есть pattern matching, как в Elixir и Erlang. Это инструмент позволяет тратить меньше сил на описание control flow. Есть трайспайлер RubyNext (как в babel в JS) - инструмент для использования новых возможностей языка на предыдущих версиях Ruby. Он помогает собрать обратную связь о нововведениях и повысить качество и скорость внедрения новых фич в языке. Но, до сих пор где-то вдохновляются RubyOnRails даже в решениях для фронта. Например sockpuppet для Django - это имплементация stimulus-reflex от Rails.

Комьюнити продолжает расширяться и собирать большие конференции по всему свету RubyKaigi (Японию), RubyRussia (Россия), Euruko (Европа), RailsConf (США), RubyConf (США) и другие.

6 Актуальность технологии

Язык и фреймворк были очень популярные в 2013-2015. Но c 2016 года появились миф что "Ruby is dead". В этих криках нет смысла т.к. любая технология проходит один и то же hype cycle. Каждая технология проходит пик завышенных ожиданий и люди считают что она устарела, хотя на самом деле после этого она выходит на плато продуктивности и это именно тот этап когда она достаточно зрелая для использовании в продакшене. Java же не умерла с 2005 года и до сих пор актуальна в продакшене.

По существу редкая технология может умереть, особенно в open source т.к. за годы на ней пишутся очень много всего, что нужно поддерживать и дальше развивать. Иначе как объяснить что по состоянию на 2023 год в рейтинге TIOBE Fortran на 16 месте? Плюс саму актуальность технологий рассчитать сложно т.к. у нас есть только косвенные способы это сделать. Кол-во вопросов на stackoverflow? Это показывает кол-во начинающих разработчиков которые учатся. Звездочки или кол-во проектов на github? Но github - это склад строительных материалов, в некоторых комьюнити не принято ставить звездочки. В серьезном энтерпрайзе не часто библиотеки публикуются публично. Вакансии на hh.ru? Это показатель нехватки специалистов в этой области на данный момент. Даже сам TIOBE рассчитывается по упоминаниям в 25 поисковых движках. Поэтому посчитать актуальность на самом деле сложно.

Подытожим

Как видно, Ruby изначально создавался как максимально удобный язык для разработки и он до сих пор он не менял своего ключевого приоритета. У него богатая стабильная экосистема с разнообразными решениями под широкий спектр задач. Он был и остается языком общего назначения и в web-разработке он до сих пор прекрасен как fullstack инструмент. А уж как писать web-приложения в комьюнити знают. У языка есть так называемые "слабые" места, но их можно преодолеть когда знаешь как и почему возникли эти особенности. Комьюнити продолжает развивать язык и инструменты вокруг него, смотрит и берет фишечки из других языков, что делает Ruby актуальным инструментом. Именно поэтому он идеально подходит под мои текущие нужды после стольких лет использования.

Дополнительно, соглашусь со словами Григория Петрова, что язык Ruby идеально подходит человеку если:

Он понимает, что ему нравится программировать и он хочет чтобы сам процесс написания кода доставлял максимальное удовольствие.
Его область интересов - помогать бизнесу. Не gamedev, не frontend, не код для физических устройств, не код для научных расчетов, не сайт-визитки. Ruby и его экосистема хороша чтобы решать бизнес задачи при помощи веб-приложения, скриптов интеграции и прочего.

Если у вас именно такие потребности, то сделать ставку на Ruby - хорошее решение!

I ❤️ Ruby

How to copy a large folder fast

Vladislav Kopylov — Wed, 20 Sep 2023 14:52:30 +0000

Having and supporting a large and old project can be very funny. Recently I've noticed one line in Capistrana deploy logs:

cp -pr node_modules tmp/node_modules
240.791s

The old project has grown and now the stage of copying the folder node_modules lasts 4 minutes. I had an idea to speed it up. First idea was to create a symlink instead of copying the folder. I've changed the line.

ls -s node_modules tmp/node_modules

It can be a good solution, but in our project we are using an old version of yarn and it can't handle it.

yarn install
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occurred: "ELOOP: too many symbolic links encountered

Next idea was to compress all node modules and decompress the folder. It can help, but it depends on the filesystem. I'be changed the script again.

tar -czf modules.tar.gz node_modules/.
tar -xzf modules.tar.gz tmp/

Fortunately, it helps me. The stage passes by 30 seconds, it's better than over 200 seconds. Remember about it that some folders on your server can get bigger and it can make your deployment slower.

Why Ruby app deploy is getting progressively slower

Vladislav Kopylov — Fri, 15 Sep 2023 16:04:16 +0000

I have a big and stable Rails application which has been running in production for 5 years. Each time I deploy the code using Capistrano and I've noticed that deploying time is getting slower. It takes 5 minutes longer than we are used to. Looking through the logs, I've noticed that the task bundle exec rake db:migrate takes 5 minutes. It was unusual!

I've done some manipulations with a deploy script. I noticed that due to the creation of new release, the first run bundle exec <COMMAND> is terribly slow. I was shocked. I had idea that there is something with code initializing or with caching.

I use Bootsnap for each my Rails application and I've noticed one thing:

Note also that Bootsnap will never clean up its own cache: this is left up to you. 
Depending on your deployment strategy, you may need to periodically purge tmp/cache/bootsnap*. 
If you notice deploys getting progressively slower, this is almost certainly the cause.

Yes, it was the answer! After some years of using Bootsnap on the server it has written caches for 180 Mbs. I have deleted all cache files using rm tmp/cache/bootsnap* and It helps me. Be aware, if you are using Bootsnap and your application is getting slower on the boost, maybe there is a problem with a large amount of cache.

Make Ruby code thread-safe

Vladislav Kopylov — Mon, 01 May 2023 13:06:02 +0000

For example, we have ruby-code that execs some I/O operations in a row (for instance, it runs 3 queries to database).

class A
  def initialize
    @data = {}
  end

  # Run class and collect data to the hash
  def call
    do_1
    do_2
    do_3
    @data
  end

  private

  def do_1
    @data['1'] = exec_some_io
  end

  def do_2
    @data['2'] = exec_some_io
  end

  def do_3
    @data['3'] = exec_some_io
  end

  def exec_some_io
    time = (0.1..0.2).step(0.01).to_a.sample
    sleep(time)
    [1,2,3].sample
  end
end

puts A.new.call

In order to optimise code and reduce execution time, we can rewrite it and use Thread.

class A
  def call
    [
      Thread.new { do_1 },
      Thread.new { do_2 },
      Thread.new { do_3 },
    ].map(&:join)
    @data
  end

  private

  def do_1
    @data['1'] = exec_some_io
  end

  def do_2
    @data['2'] = exec_some_io
  end

  def do_3
    @data['3'] = exec_some_io
  end
end

Please, don't write the code like that. Firstly, methods do_1, do_2, do_3 know a lot of information about the data structure. Secondly, as we are using threads, we don't control context. It's dangerous and can produce errors in our application. In order to fix it, we have to use value method. It's easy to rewrite:

class A
  def call
    @data = {
      '1' => Thread.new { do_1 },
      '2' => Thread.new { do_2 },
      '3' => Thread.new { do_3 },
    }.transform_values(&:value)
    @data
  end

  private

  def do_1
    exec_some_io
  end

  def do_2
    exec_some_io
  end

  def do_3
    exec_some_io
  end
end

Now, our ruby-code is thread-safe.

Using ChatGPT 1: Setup local environment

Vladislav Kopylov — Sat, 01 Apr 2023 15:39:19 +0000

I have experience with using ChatGPT, but I didn’t consider it an everyday tool for a programmer. I’ve changed my job, got a MacBook with Ventura OS, a welcome pack and started to set up local environment. My new project is a big system written on RubyOnRails with SPA written on reactJS. Of course, I did it before and I didn’t think there would be any problems. Unfortunately, I had problems with setting up local environment for the SPA application, specifically with installing node-gyp. I’ve tried different nodeJS versions and I’ve asked my team leader for help. We didn’t find any solution. I was frustrated and my working day was wasted.

In the evening I came back home and decided to ask ChatGPT for setting up local environment for the SPA application. Honesty, I didn’t think it would help. I decided to do it just for fun. I poured a cup of tea and opened chat.openai.com. I’ve sent an error to ChatGPT, it asked me about my local environment and tried to help me. It suggested changing my nodeJS version, use FORCE_PREBUILT_MODULES flag, etc, but we still had problems. After 45 minutes it wrote me to install all packages with —ignore-scripts and it worked for me. I have installed fsevents, node-gyp and other packages. It worked like a magic, I didn’t believe that ChatGPT have helped me. Wow, I was surprised and so excited! It’s a big thing and I will continue to use it for my job tasks.

Crafting mini RubyOnRails

Vladislav Kopylov — Tue, 10 May 2022 16:27:37 +0000

Introduction

Once I watched Maple Ong's talk Building a Ruby web app using the Ruby Standard Library on Euruko 2021. The talk inspired me and I've got an idea to write a little web-server from scratch. Then I started to improve the original script and decided to write an MVC-framework as RubyOnRails on plain Ruby. Such a good challenge.

I called it MiniRails, the source code is available in mono repo on GitHub. In the article I describe the process of creating the library. The goal of the article is to describe which concepts and ideas I used: how MVC layers work, how router matches a client request and how I implemented a test library. Some code examples are short to show the main concept without excess amount of code. If you want to look deeper, there is always links to the course code on Github. I hope my experience will be useful for readers.

Build a rack middleware

Begin with writing a rack-middleware. Rack is a standard library for writing a web server. The main structure is simple. Here is an example:

module MiniActionDispatch
  # Rack-middleware to render hello world page
  class HelloHandler
    # Receive rack-env and build response in rack format
    def call(env)
      [200, { "Content-Type" => 'text/html' }, ["<h1>Hello to Ruby on MiniRails</h1>"]]
    end
  end
end

Middleware for the application looks like this. At the first sight it's more difficult example, but the algorithm is clear.

# Rack-middleware to handler rack-request
class MiniActionDispatch::RequestHandler
  def call(env)
    # Wrap data to convenient interface
    req = Rack::Request.new(env)

    # Fetch params from a request
    method_token = req.request_method
    path = req.path || req.path_info

    # Wrap params to data-object to handle request params and http-headers
    action_params = ::MiniActionParams.parse(req)
    params = action_params.params
    headers = action_params.headers

    # DELETE, PUT, PATCH support
    if method_token == 'POST' && ['DELETE', 'PUT', 'PATCH'].include?(params[:_method]&.upcase)
      method_token = params[:_method].upcase
    end

    # Match path with route map and find the controller to handle request
    selected_route = MiniActiveRouter::Base.instance.find(method_token, path)
    controller_name, controler_method_name = selected_route.controller_data
    # Route's placeholder support such as :id
    placeholders = selected_route.parse_placeholders(path)
    params = params.merge(placeholders)

    # Find a controller
    controller_class = Object.const_get "#{controller_name.camelize}Controller"
    controller = controller_class.new(params, headers)

    # Run controller's action
    # Construct the HTTP response and return it
    controller.build_response(controler_method_name)
  end
end

The algorithm has 3 steps:
* Handle user request data
* Match route and find a controller
* Pass data to controller and execute a method

Dive deeper and look how the router works

For routing I've written MiniActiveRouter module. My goal was to implement basic algorithm from Rails router, such as in the example below:

MiniActiveRouter::Base.instance.draw do
  get '/', to: 'home#index'

  # Group scope - JSON
  get '/api/groups', to: 'api/groups#index'
  get '/api/groups/:id', to: 'api/groups#show'
  post '/api/groups', to: 'api/groups#create'
  patch '/api/groups/:id', to: 'api/groups#update'
  delete '/api/groups/:id', to: 'api/groups#destroy'

  not_found to: 'not_found#index'
end

There are get, post, patch, put, delete functions to define routes and not_found method for 404 page handler. Routes also support placeholders such as "id" in path. MiniActiveRouter::Base is a singleton class, current code is here. The singleton stores array of routes in @map variable and holds a route for 404 page in @fallback_route variable.

class MiniActiveRouter::Base
  include ::Singleton

  def initialize
    @map = []
    @fallback_route = nil
  end

  # NOTE: Method for drawing routes map
  # Use it in config/router.rb file
  def draw(&block)
    instance_eval &block
  end

  # @param path [String, Regexp]
  # @param arg [Hash]
  # NOTE: post, delete, put, patch method are similar
  def get(path, arg)
    write_to_map('GET', path, **arg)
  end

  # NOTE: Method for set a route for 404 page
  def not_found(to: )
    @fallback_route = Route.new(nil, nil, to: to)
  end

  private
  def write_to_map(method, path, to:)
    transformed_path = transform_path(path)
    @map << Route.new(method, transformed_path, to: to)
  end
end

Drawing routes algorithm isn't difficult. For draw function it uses instance_eval , it make the code inside the do-end block plain and easy to read. get, post, patch, etc methods are just wrappers for write_to_map function.

Adding placeholder in path feature wasn't a trivial task. I wanted to define a route in the following manner:

patch '/api/groups/:id', to: 'api/groups#update'
patch '/groups/:group_id/items/:id', to: 'items#update'

The easiest way I figured out is using regular expressions. Regexp has groups feature. For route /api/groups/:id we can write a regexp /\/api\/groups\/(?<id>[0-9]*)/ and it will match group "id".

"/api/groups/123" =~ /\/api\/groups\/(?<id>[0-9]*)/
# => 0
match_data = Regexp.last_match
# => #<MatchData "/api/groups/123" id:"123">

For placeholders feature I've written the method transform_path. It match placeholders, if they are here it converts string to a regexp.

class MiniActiveRouter::Base
  # If a string has placeholders (for example "items/:id")
  # It converts string to regexp with groups (for example /items\/(:id[0-9a-zA-Z]*)/)
  def transform_path(path)
    # 1: Find all placeholders
    placeholders = path.scan(/:[0-9a-zA-Z\-_]*/)
    return path if placeholders.size == 0

    # 2: Replace each placeholder to (?<placeholder_name>[0-9a-zA-Z]*)
    placeholders.each do |placeholder|
      path = path.gsub(placeholder, "(?<#{placeholder}>[0-9a-zA-Z\\-_]*)")
    end

    # 3: Return the route as an regexp
    return Regexp.new("^#{path}$")
    end
  end
end

How does the route matching work? There is a line of code in the the previous rack-middleware. Method .find receives a method token, a path and matches data with all available routes.

selected_route = MiniActiveRouter::Base.instance.find(method_token, path)
# Example: MiniActiveRouter::Base.instance.find('GET', '/items/1234')

Under the hood, the algorithm is simple: match all routes, if there is not a match return the default route if it exists.

class MiniActiveRouter::Base
  # NOTE: it iterates each route from @map
  # Returns matched router or @fallback_route
  # @param method [String]
  # @param path [String]
  # @return [Route]
  def find(method, path)
    matched_route = @map.find{ |route| route.match?(method, path) }
    if matched_route.present?
      matched_route
    elsif @fallback_route.present?
      @fallback_route
    else
      raise "ERROR: Can't find route for #{method}##{path}"
    end
  end
end

Controllers layer

After the matching, we know which controller could handle the client request. Below you can see the code from rack-middleware.

controller_name, controler_method_name = selected_route.controller_data
# Find controller
controller_class = Object.const_get "#{controller_name.camelize}Controller"
controller = controller_class.new(params, headers)

# Run controller's action
# Construct the HTTP response and return it
controller.build_response(controler_method_name)

Inside the application a controller looks familiar as an average controller in Ruby On Rails application.

class ItemsController < ApplicationController
  before_action :find_group

  def index
    @items = @group.items.sort_by(&:active?).map{ |i| ItemDecorator.new(i) }
    render :index
  end

  def create
    @item = Item.new(permited_params)
    if @item.save
      redirect_to "/groups/#{@group.id}/items"
    else
      @alert = @item.errors.full_messages.join(', ')
      render :new, status: '422 Unprocessable Entity'
    end
  end

  private
  def find_group
    @group = Group.find(params[:group_id])
  end
end

Also it supports before_action callback and rescue_from handler.

class ApplicationController < MiniActionController::Base
  rescue_from ::MiniActiveRecord::RecordNotFound, with: :not_found

  private
  def not_found
    render('not_found/index', status: '404 Not Found')
  end
end

Let's look how #build_response method works.

class MiniActionController::Base
  # @param controler_method_name [String, Symbol]
  def build_response(controler_method_name)
    begin
      # 1: Run all callbacks
      run_callbacks_for(controler_method_name.to_sym)
      # 2: Run the controller action
      response = public_send(controler_method_name)
    rescue StandardError => e
      # 3: If there is an exception, try to find :rescue_from handler
      response = try_to_rescue(e)
    end
    build_rack_response(response)
  end
end

There are few steps:
* Run all callbacks if they exist
* Run the controller action
* Build a standard rack response
* If it catches an error, it tries to rescue the exception

Callbacks

How to define and run callbacks? You can see the code in MiniActionController::Callbacks module. There is the method before_action in MiniRails. Using it we can define callbacks with conditions such as:

before_action :method_name, only: [:index, :show], unless: -> { @foo.nil? }
before_action :method_name, except: [:index, :show], if: -> { @foo }

before_action method stores data in callbacks. In order to share data between class and class instance I use the class_attribute feature from ActiveSupport . Here is the link to docs. It's very useful feature, I like it and often use it.

module MiniActionController::Callbacks
  def self.included(base)
    base.class_attribute :callbacks
    base.callbacks = []
  end
end

Return to MiniActionController::Base#build_response method, run_callbacks_for method iterates each before_action defined callback, matches conditions such as only:, except:, if:, unless: and then it executes a method.

Rescuing

How to rescue an exceptions? You can see the code in MiniActionController::Rescuable module.

module MiniActionController::Rescuable
  def self.included(base)
    base.class_attribute :rescue_attempts
    base.rescue_attempts = []
    base.extend ClassMethods
  end

  private
  # NOTE: Find first handle for the exception and run
  # @param exception [StandardError]
  def try_to_rescue(exception)
    rescue_attempt = self.class.rescue_attempts.find do |meta|
      exception.is_a?(meta[:exception])
    end
    raise exception if rescue_attempt.nil?

     send(rescue_attempt[:with])
  end

  module ClassMethods
    # Example of usage:
    # rescue_from User::NotAuthorized, with: :deny_access
    # rescue_from ActiveRecord::RecordInvalid, with: :show_errors
    # @param exception [StandardError]
    # @param with [String, Symbol]
    def rescue_from(exception, with: nil)
      rescue_attempt = { exception: exception, with: with }
      self.rescue_attempts = self.rescue_attempts + [rescue_attempt]
    end
  end
end

Algorithm is similar. It uses the class attribute rescue_attempts to store rescue handlers. Function rescue_from adds data to rescue_attempts, method try_to_rescue receives an exception and tries to find a handle.

Views layer

Rendering

We saw how controllers layer works, let's see how it renders views. For views layer I've implemented MiniActionView namespace. For view files I use ERB-files, because it's simple and familiar to use. Example of a simple view:

# Controler method
def new
  @group = Group.new
  render :new, status: "200 OK"
end

# View new.html.erb file
<h2>Create new group</h2>

<%= render_partial 'shared/_new_group_form', locals: { item: @group } %>

<a href="/">Go to back</a>

It supports partial file render, and received instance variables from a controller method.

How are controllers layer and views layer connected and how it passes instance variables from controller method to a view? The easiest way is to include MiniActionView module to MiniActionController, but I don't consider it as a good idea, I prefer a different way.

Let's see how method render works. The code inside MiniActionController::Render module collects all instance variables inside collect_variables method and passes data as a Hash to a MiniActionView::Base instance.

module MiniActionController::Render
  # @param view_name [String, Symbol]
  # @param status [String]
  # @return [MiniActionController::Response]
  def render(view_name, status: MiniActionController::DEFAULT_STATUS)
    # collect and forward instance variables to MiniActionView::Base
    variables_to_pass = collect_variables
    MiniActionView::Base.new(variables_to_pass, entity).render(view_name, status: status)
  end

  private
  def collect_variables
    instance_variables.reduce({}) do |memo, var_symbol|
      memo[var_symbol] = instance_variable_get(var_symbol)
      memo
    end
  end
end

The render method of MiniActionView::Base class executes render_view function in order to render ERB-file and it returns a value-object as a result

module MiniActionView::Base
  # @param view_name [String, Symbol]
  # @param status [String]
  # @param content_type [String] html by default
  # @return [MiniActionController::Response]
  def render(view_name, status: MiniActionController::DEFAULT_STATUS, content_type: 'html')
    response_message = render_view("#{view_name}.html.erb")
    MiniActionController::Response.new(
      status: status, response_message: response_message, content_type: content_type, headers: {},
    )
  end
end

You can see the rendering algorithm in MiniActionView::Render module, here is the main logic in the snippet below:

module MiniActionView::Render
  # NOTE: If view_name has `/` symbol it searches for a file in app/views folder
  # If view_name hasn't `/` symbol it searches for a file in entity folder
  def render_view(view_name, locals: {})
    root_path = MiniRails.root.join('app', 'views')
    root_path = root_path.join(entity) unless view_name.include?('/')
    view_path = root_path.join(view_name).to_s

    # assign data from locals: as local variables
    local_binding = binding
    locals.each do |key, value|
      local_binding.local_variable_set(key, value)
    end
    ERB.new(read_or_open(view_path)).result(local_binding)
  end
end

The locals argument is used to pass value to a view. In Rails you used to write something like render form, locals: {zone: @zone, item: @item}. In order to pass data to ERB-file I create a copy of current binding, assign data and pass the variable local_binding to result method.

In the same module you can see the code how to render partial views inside a current view. render_partial is a function to render a partial view. Under the hood it's just a wrapper for private render_view function.

module MiniActionView::Render
  # @param view_name [String, Symbol]
  # @param collection [Array<Object>] each item will be passed as 'item' variable
  # @param locals [Hash<Symbol,Object>] params to passing data as local_variables
  def render_partial(view_name, collection: [], locals: {})
    if collection.size > 0
      collection.map { |i| render_view(view_name, locals: {item: i}) }.join('')
    else
      render_view(view_name, locals: locals)
    end
  end
end

Layout

When view is already rendered it's time to render a layout. You can see the code in MiniActionView::Layout class. The render_response method renders layout with the result of controller's action and builds a rack response.

# Note: Class to render layout for views.
# ERB-file that contains layout-template must be in app/views/layouts/ folder
# For example 'app/views/layouts/application.html.erb'
class MiniActionView::Layout < ::MiniActionView::Base
  # @param layout [String, Symbol]
  # @param response [MiniActionController::Response]
  def render_response(layout, response)
    status_code, _status_text = response.status.split(' ')
    additional_headers = response.headers.map{ |k,v| "#{k}: #{v}" }.join("\n\r")
    headers = {"Content-Type" => "text/html"}.merge(response.headers)
    response_body = render_layout(layout) { response.response_message }
    # Construct the Rack response
    [status_code, headers, [response_body]]
  end

  private
  def render_layout(layout_name)
    view_path = MiniRails.root.join('app', 'views', self.entity, "#{layout_name}.html.erb").to_s
    ERB.new(read_or_open(view_path)).result(binding)
  end
end

JSON response

MiniRails also supports JSON-responses and serialiser-objects for ruby objects. In a controller you able to write the code as:

class Api::GroupsController < ::Api::ApplicationController
  before_action :groups, only: [:index]
  before_action :group, only: [:show, :update, :destroy]

  def index
    render_json(@groups, each_serializer: GroupSerializer)
  end

  def show
    render_json(@group, serializer: GroupSerializer)
  end
end

The source code also locates in MiniActionController::Render module, it's able to receive different data types:

module MiniActionController::Render
  # Examples of usage:
  # String: render_json({a: 123}.to_json)
  # Array: render_json([1,2,3])
  # Array with root: render_json([1,2,3], root: 'data')
  # Object. render_json(Item.all)
  # With serializer: render_json(Item.first, serializer: ItemSerializer)
  # With each_serializer: render_json(Item.all, each_serializer: ItemSerializer)
  #
  # @param object [String, Hash, Object]
  # Object should respond to .as_json and return Hash
  # @param opts [Hash]
  # @option opts [String] :status Http status
  # @option opts [Object] :serializer child of MiniActiveRecord::Serializer
  # @option opts [Object] :each_serializer Param object should be Array
  # @option opts [String] :root
  # @return [MiniActionController::Response]
  def render_json(object, opts = {})
    status = opts[:status] || MiniActionController::DEFAULT_STATUS
    MiniActionView::Json.new(object).render(opts.merge(status: status))
  end
end

The function is just a wrapper for MiniActionView::Json#render method. Layout for JSON response works similar as HTML layout algorithm.

Assets rendering

The library supports JS and CSS assets rendering. There are stylesheet_link_tag and javascript_include_tag methods in a layout template (ERB file) to render HTML-tags.

# todo_list/app/views/layouts/application.html.erb
<!DOCTYPE html>
<html lang="ru">
<head>
  <title>My TODO list</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
  <%= stylesheet_link_tag "application" %>
  <%= javascript_include_tag "application" %>
# …

A file with stylesheets can look like:

# todo_list/app/assets/stylesheets/application.css.erb
<%= import 'bootstrap' %>
<%= import 'bootstrap_pricing' %>

/* custom styles */
p.disabled {
  color: #6c757d
}

It renders partial files bootstrap , bootstrap_pricing via import method and has its own css-styles. The algorithm of partial files rendering are written in MiniActionView::Asset class.

class MiniActionView::Asset
  # It renders text file and ERB files
  # @param file_path [String]
  # @return [String]
  def render(file_path = nil)
    file_path ||= @original_file_path
    file_context = File.open(file_path).read
    if file_path.to_s =~ /\.erb$/
      ERB.new(file_context).result(binding)
    else
      file_context
    end
  end

  private
  def import(file_name)
    @original_file_path = @current_folder.join("#{file_name}#{@file_extention}")
    # Try to find original file or file with .erb
    if File.exist?(@original_file_path)
      render(@original_file_path)
    elsif File.exist?("#{@original_file_path}.erb")
      render("#{@original_file_path}.erb")
    else
      raise "ERROR: Can not open file '#{@original_file_path}'"
    end
  end
end

In assets file we can use import method which is just a wrapper for render function.

How to handle client request, compile assets and return response? For it there is MiniActionDispatch::AssetHandler rack-middleware.

# Rack-middleware to handler request and render assets
class MiniActionDispatch::AssetHandler
  def initialize(app)
    @app = app
  end

  # NOTE: Attempt to find asset by path.
  # If doesn't find a file, pass the request to another middleware
  def call(env)
    attempt(env) || @app.call(env)
  end

  private
  def attempt(env)
    request = Rack::Request.new(env)
    return nil unless valid_request?(request)

    path_info = request.path_info
    file_path = find_original_file(path_info)
    if file_path.present?
      file_context = ::MiniActionView::Asset.new(file_path).render
      # Build rack answer
      return [200, build_headers(path_info), [file_context]]
    end
    # Return nil in order to pass request to another middleware
    nil
  end
end

JS-asset files are rendered absolutely the same way.

Models layer

In order to implement a models layer I've written the MiniActiveRecord module. A standard model looks like:

class Item < MiniActiveRecord::Base
  attribute :title, type: String
  attribute :group_id, type: String
  attribute :done, type: [TrueClass, FalseClass], default: false

  validates :title, presence: true, length: { max: 100, min: 3 }
  validates :group_id, presence: true

  belongs_to :group

  scope :active, -> { where(done: false) }
  scope :not_active, -> { where(done: true) }
end

There are attributes, validations, relations and scopes. Let's look at the code deeper.

Attributes

Firstly, I had to define attributes. I wanted to have an interface which is similar to mongoid. The code is incapsulated in MiniActiveRecord::Attribute module.

module MiniActiveRecord::Attribute
  def self.included(base)
    base.extend ClassMethods
    # Define storage to collect info about all defined attributes.
    base.class_attribute :fields
    base.fields = []

    # Define base attributes.
    base.attribute :id, type: String
    base.attribute :created_at, type: DateTime
  end

  module ClassMethods
    # @param field_name [String, Symbol]
    # @option options [Class, Array<Class>] :type
    # @option options [Object] :default The field's default
    def attribute(field_name, type: String, default: nil)
      new_field_params = { name: field_name.to_sym, type: type, default: default }
      self.fields = fields | [new_field_params]

      instance_eval do
        # Define a getter
        define_method(field_name) do
          field_params = fields.find{ |i| i[:name] == field_name.to_sym }
          instance_variable_get("@#{field_name}") || field_params[:default]
        end

        # Define a setter
        define_method("#{field_name}=") do |value|
          # CODE
          instance_variable_set("@#{field_name}", value)
        end
      end
    end
  end
end

I use class_attribute feature to collect info about all implemented attributes to fields variable. attribute method saves data to fields variable, defined getter and setter with meta programming.

Relations

Relations feature is one of the easiest and smallers part. You can see the code inside MiniActiveRecord::Association module.

# NOTE: Module with assiciation logic, such as: has_many, belongs_to, etc.
module MiniActiveRecord::Association
  # Example of usage: has_many :items
  # It will create method .items
  # The method returns Array
  # @param assosiation_name [String, Symbol]
  # @param class_name [String] Model name
  def has_many(association_name, class_name:)
    instance_eval do
      define_method(association_name) do
        another_model = Object.const_get(class_name)
        attribute = "#{self.class.name.downcase}_id"
        another_model.where(attribute.to_sym => id)
      end
    end
  end

  # Example of usage: has_many :user
  # It will create method .user
  # The method returns Object
  # @param assosiation_name [String, Symbol]
  def belongs_to(association_name)
    instance_eval do
      define_method(association_name) do
        class_name = association_name.to_s.camelize
        another_model = Object.const_get(class_name)
        refer_id = public_send("#{association_name}_id")
        another_model.find(refer_id)
      end
    end
  end
end

I've written has_many and belongs_to relations. Both methods create other methods with meta programming. The logic is clear and it doesn't work like a magic.

Validations

So, we have attributes and relations. It's time for validations. The code is written inside MiniActiveRecord::Validation module.

module MiniActiveRecord::Validation
  def self.included(base)
    base.class_attribute :validations
    base.validations = []
    base.extend ClassMethods
  end

  module ClassMethods
    # Example of usage:
    #   validates :title, presence: true
    #   validates :title, length: { max: 100, min: 3 }
    # @param field_name [String, Symbol]
    # @param presence [Boolean]
    # @param length [Hash]
    # @option length [Number] :max
    # @option length [Number] :min
    def validates(field_name, presence: nil, length: {})
      if presence.present?
        validates_presence_of(field_name)
      end
      if length.present?
        validates_length_of(field_name, max: length[:max], min: length[:min])
      end
    end

    # @param field_name [String, Symbol]
    def validates_presence_of(field_name)
      new_validation = { field_name: field_name.to_sym, type: :presence_of }
      self.validations = validations | [new_validation]
    end

    def validates_length_of(field_name, max: nil, min: nil)
      new_validation = { field_name: field_name.to_sym, type: :length_of, max: max, min: min }
      self.validations = validations | [new_validation]
    end
  end
end

I again use class_attribute feature in order to store meta data about all validations in the validations variable. Then I defined two methods for validations validates_presence_of , validates_length_of and wrote a wrapper validates to use it easily.

Each validation class is an implementation of visitor OOP-pattern. It makes it easy to read the code and add one more validation.

# validation/presence_of_validation
# NOTE: Validation class that checks existence of a value
class MiniActiveRecord::Validation::PresenceOfValidation < BaseValidation
  def call
    value = object.public_send(field_name)
    return true if value.present?

    object.errors.add(field_name, 'must be present')
  end
end

# validation/length_of_validation
# NOTE: Validation class that checks string length
class MiniActiveRecord::Validation::LengthOfValidation < BaseValidation
  def call
    value = object.public_send(field_name)
    return if value.nil?

    max = meta_data[:max]
    min = meta_data[:min]
    if max.present? && value.size > max
      object.errors.add(field_name, "must be less then #{max}")
    end
    if min.present? && value.size < min
      object.errors.add(field_name, "must be greater then #{min}")
    end
  end
end

How to run all validations? The algorithm is the same as in RubyOnRails, method valid? runs all validations.

module MiniActiveRecord::Validation
  def valid?
    validate!
    errors.size == 0
  end

  # Runs all validations
  def validate!
    # 1: Init new error-object
    @errors_object = ::MiniActiveRecord::Validation::Errors.new
    validation_namespace = ::MiniActiveRecord::Validation
    # 2: Run each validation
    self.validations.each do |validation|
      class_object = "#{validation[:type].to_s.camelize}Validation"

      if validation_namespace.const_defined?(class_object)
        klass = validation_namespace.const_get(class_object)
        klass.new(validation, self).call
      else
        raise "ERROR: Can not find class #{validation_namespace}::class_object"
      end
    end
    self
  end

  # @return [MiniActiveRecord::Validation::Errors]
  def errors
    @errors_object
  end
end

User can explicitly run valid? method, or the library can do it implicitly using save, or save! methods. Example:

# Code in controller
def create
  @item = Item.new(permited_params)
  if @item.save
    redirect_to "/groups/#{@group.id}/items"
  else
    render :new, status: '422 Unprocessable Entity'
  end
end

module MiniActiveRecord::Operate
  # @return [Boolean]
  def save
    return false unless valid?
    # CODE is here
    true
  end

  # @return [Boolean]
  # @raise MiniActiveRecord::RecordInvalid
  def save!
    if save
      true
    else
      raise MiniActiveRecord::RecordInvalid
    end
  end
end

Scopes and querying

Querying is a very important part of the models layer. We are used to write code like this:

Group.where(id: '123')
Item.where(group_id: '123')
Item.find('123)

Scoping is also very important. We are used to write code in a model like that, instead of defining new method.

class Item < MiniActiveRecord::Base
  attribute :done, type: [TrueClass, FalseClass], default: false

  scope :active, -> { where(done: false) }
  scope :not_active, -> { where(done: true) }
end

Under the hood, the scope-feature just a stroring meta data about each ruby Proc in a global variable for future use and define new singleton method in the model class. The source code is incapsulated in MiniActiveRecord::Scope module.

module MiniActiveRecord::Scope
  def self.included(base)
    base.extend ClassMethods
    base.class_attribute :scopes
    base.scopes = []
  end

  module ClassMethods
    # @param name [String, Symbol]
    # @param procc [Proc]
    def scope(name, procc)
      new_scope_params = { name: name.to_sym, proc: procc }
      self.scopes = scopes | [new_scope_params]
      self.class_eval do
        define_singleton_method(name, &procc)
      end
    end
  end
end

I again use class_attribute feature and store data in scopes variable for future use. There is no magic. The magic you will see below, querying should support chain methods like:

Group.first.items.active.count
Group.first.items.where(done: false).count
Record.where(a: 'foo').where(b: 'bar')

In order to do it I wrote MiniActiveRecord::Relation module and defined methods as all, where, find_by etc.

module MiniActiveRecord::Relation
  # @param conditions [Hash<Symbol, Object>] Object could be String, Integer, Array
  # @return [MiniActiveRecord::Proxy]
  def where(conditions = {})
    init_proxy.where(conditions)
  end

  # @param conditions [Hash<Symbol, Object>] Object could be String, Integer, Array
  # @return [MiniActiveRecord::Base]
  def find_by(conditions)
    where(conditions).first
  end

  # @param conditions [Hash<Symbol, Object>] Object could be String, Integer, Array
  # @return [Object]
  # @raise [MiniActiveRecord::RecordNotFound]
  # @return [MiniActiveRecord::Base]
  def find_by!(conditions)
    item = where(conditions).first
    raise ::MiniActiveRecord::RecordNotFound if item.nil?
    item
  end

  # @return [MiniActiveRecord::Proxy]
  def all
    where({})
  end

  # @return [MiniActiveRecord::Base]
  # @raise [MiniActiveRecord::RecordNotFound]
  def find(selected_id)
    find_by!({id: selected_id})
  end

  private
  def init_proxy
    # proxy_class is a child of MiniActiveRecord::Proxy
    self.proxy_class.new({})
  end
end

The main method is where, other functions are just wrappers for the function. The where method passes all arguments to MiniActiveRecord::Proxy class. The proxy class is similar to ActiveRecord::Associations::CollectionProxy. It's an implementation of the proxy patter and it's useful for chain methods.

class MiniActiveRecord::Proxy
  # @param where_condition [Hash]
  def initialize(where_condition = {})
    @where_condition = where_condition.transform_keys(&:to_sym)
    @limit = nil
  end

  # @return [MiniActiveRecord::Proxy]
  def all
    where({})
    self
  end

  # @return [MiniActiveRecord::Proxy]
  def where(conditions)
    @where_condition.merge!(conditions.transform_keys(&:to_sym))
    self
  end

  private
  def method_missing(message, *args, &block)
    # The magic is here
  end
end

Each public method returns self, it supports the chain methods. The main magic locates inside method_missing. Firstly, the methods chain should support scopes I stored in scopes variable. Secondly, a proxy should extract data from a database and return an array of MiniActiveRecord::Base objects for us. It's urgent for code like that:

class Item < MiniActiveRecord::Base
  scope :active, -> { where(done: false) }
  scope :not_active, -> { where(done: true) }
end

# .each and .map are methods of Array, not MiniActiveRecord::Proxy
Items.all.active.each { |i| puts i.id }
Items.where(a: 'foo').map { |i| i.do_something }

I wrote the method_missing method which tries to find a scope (actual for active, not_active scopes). If there is no scope, it passes the data to DB driver and wrap raw data into MiniActiveRecord::Base (it's our models Item, Group, etc).

class MiniActiveRecord::Proxy
  # NOTE: Use it in order to exec driver even before data manitulation
  # It pass methods to Array<ActiveRecord::Base>
  # For example:
  # .where().each {}
  # .where().where().map {}
  def method_missing(message, *args, &block)
    # 1: Try to find scope in the model class
    scope_meta = model_class.scopes.find{ |i| i[:name] == message }
    if !scope_meta.nil?
      instance_exec(&scope_meta[:proc])
    else
      # 2: Execute and find method
      execute.public_send(message, *args, &block)
    end
  end

  # Run driver and wrap raw data to a model-class
  # @return [Array<ActiveRecord::Base>]
  def execute
    raw_data = driver.where(@where_condition, table_name, @limit)
    raw_data.map { |data| model_class.new(data) }
  end
end

Data storages

Inspired by Maple Ong's talk, I keep using a yaml-file storage. With the template method OOP-pattern, it's possible to write a driver for different databases in future such as: MongoDB, SQL or Redis. But now I'm good with just a yaml file.

Firstly I implemented an abstract class MiniActiveRecord::Driver with interface.

# NOTE: Abstract class.
# Inherite from the class in order to implement a driver for different DBs.
class MiniActiveRecord::Driver
  class << self
    # @param table_name [String]
    def all(table_name)
      _all(table_name)
    end

    # @param conditions [Hash<Symbol, Object>]
    # @param table_name [String]
    # @param limit [Integer]
    def where(conditions, table_name, limit)
      _where(conditions, table_name, limit)
    end

    # @param selected_id [String, Integer]
    # @param table_name [String]
    def find(selected_id, table_name)
      _find(selected_id, table_name)
    end
    # CODE
  end
end

Then, I inherited MiniActiveRecord::YamlDriver class with low-level code described how to store and manipulate the data from a yaml file.

# NOTE: Driver for YAML-file local data storage
class MiniActiveRecord::YamlDriver < MiniActiveRecord::Driver
  class << self
    private
    def _all(table_name)
      _where({}, nil, table_name)
    end

    def _find(selected_id, table_name)
      _where({id: selected_id}, 1, table_name)
    end

    def _where(conditions, table_name, limit = nil)
      store = init_store(table_name)
      store.transaction do
        memo = store[table_name.to_sym]
        memo = conditions.reduce(memo) do |memo, (cond_key, cond_value)|
          if cond_value.is_a?(Array)
            memo.select{ |i| cond_value.include?(i[cond_key])  }
          else
            memo.select{ |i| i[cond_key] == cond_value }
          end
        end
      memo
    end

    def init_store(table_name)
      full_file_path = MiniRails.root.join("db/db_#{table_name}.yml")
      YAML::Store.new(full_file_path)
    end
  end
end

Testing

These three MVC layers and a rack-middleware are enough to write an application. In order to prove that it works, I had to write a library for testing. I had an idea to write something like RSpec from scratch.

Fabrics

Firstly I had to implement a library for fabrics such as FactoryBot. My goal was to implement a factory definition with sequence and trait. I called it MiniFactory and I wanted be able to write the code as:

# todo_list/spec/factories/item_factory.rb
MiniFactory.define do
  factory :item, class: 'Item' do
    sequence(:title) { |i| "title_#{i}" }
    done { false }

    trait :done do
      done { true }
    end
  end
end

Start with the factory definition. MiniFactory::define is just a syntax sugar for MiniFactory::Base .

module MiniFactory
  class << self
    def define(&block)
      Base.instance.instance_exec(&block)
    end
  end
end

MiniFactory::Base class is a singleton object which stores the information about defined factories in the @factories variable.

class MiniFactory::Base
  include Singleton
  def initialize
    @factories = {} # Hash to store data about all factories
  end

  # @param factory_name [String, Symbol]
  # @param opts [Hash<Symbol, Object>]
  # @option opts [Object, String] :class
  def factory(factory_name, opts, &block)
    buidler = Builder.new(opts[:class])
    buidler.instance_exec(&block)
    @factories[factory_name.to_sym] = { count: 0, buidler: buidler }
  end
end

In order to define various model attributes I wrote MiniFactory::Builder class which is similar to the factory OOP-pattern. Look at example below, each model has different attributes such as title and done for item factory. How to support it?

MiniFactory.define do
  factory :item, class: 'Item' do
    title { 'Hello' }
    done { false }
  end
end

There is the method_missing method to cope with it. It stores a model attribute name in the @attributes variable and also stores the Proc.

class MiniFactory::Builder
  def initialize(klass)
    @klass = klass
    @attributes = {}
  end

  def method_missing(message, *args, &block)
    @attributes[message] = { type: :attribute, block: block }
  end
end

So, I have all information to create a factory, let's do it. In order to build a factory, I've written the code:

MiniFactory.build(:item)

module MiniFactory
  # @param factory_name [Symbol, String]
  # @param traits_and_opts [Array]
  def self.build(factory_name, *traits_and_opts)
    opts = traits_and_opts.extract_options!
    traits = traits_and_opts.map(&:to_sym)
    Base.instance.build_factory(factory_name, traits, opts)
  end
end

class MiniFactory::Base
  # @param factory_name [String, Symbol]
  # @param traits [Array<Symbol>]
  # @param opts [Hash<Symbol, Object>]
  def build_factory(factory_name, traits, opts)
    # Find MiniFactory::Builder instance
    buidler = @factories[factory_name.to_sym][:buidler]
    # Build new object
    buidler.build_object(number, traits, opts)
  end
end

class MiniFactory::Builder
  # @param number [Integer] Params for sequences
  # @param selected_traits [Array<Symbol>]
  # @param opts [Hash<Symbol, Object>]
  def build_object(number = 1, selected_traits = [], opts = {})
    @klass = Object.const_get(@klass)
    # 1: Collect all attributes
    all_attributes = (opts.keys + @attributes.keys).uniq

    # 3: Assign data from opts params or fetch it from stored proc
    attrs = all_attributes.reduce({}) do |memo, key|
      memo[key] = (opts.key?(key) ? opts[key] : @attributes[key][:block].call)
      memo
    end
    # 4: Assign data to a model instance
    @klass.new(**attrs)
  end
end

Let's add sequence feature. The Sequence is a method for a factory class. It stores data as I wrote in method_missing but with different type. And let's improve fetch_params method to pass a number to sequence's Proc.

class MiniFactory::Builder
  # Example of usage:
  # senquence(:title) { |i| "My title ##{i}" }
  # @param attr_name [String, Symbol]
  def sequence(attr_name, &block)
    @attributes[attr_name.to_sym] = { type: :sequence, block: block }
  end

  def fetch_params(params, number)
    if params[:type] == :attribute
      params[:block].call
    else
      # If the attribute is sequence, pass a number
      params[:block].call(number)
    end
  end
end

What about trait feature? Trait is a factory inside a factory :-)

class MiniFactory::Builder
  def initialize(klass)
    @traits = {}
  end

  # @param trait_name [String, Symbol]
  def trait(trait_name, &block)
    trait_builder = self.class.new(@klass)
    trait_builder.instance_exec(&block)
    @traits[trait_name.to_sym] = trait_builder.attributes
  end
end

Testing and specs

I decided to implement the core functional of RSpec and called it MiniRSpec. Firstly, I had to implement a test tree feature. It's a bunch of methods like context, describe, and it. With these methods I'm able to write a test tree.

MiniRSpec.describe 'Item' do
  describe 'context 1' do
    it 'works' {}
    describe 'context 1.1' do
      it 'works' {}
    end
  end
  describe 'context 2' do
    it 'works' {}
  end
end

It was a real challenge. The structure of the code is an AST (abstract syntax tree), therefore there are 3 types of AST leaves:

Main leaf MiniRSpec.describe
Context leaf context and describe
Test leaf it

Let's begin with a data storage and the main leaf.

# mini_rails/mini_r_spec/base.rb
# Singleton class to store test data as AST in @ast variable
class MiniRSpec::Base
  attr_accessor :ast
  include ::Singleton

  def initialize
    @ast = []
  end
end

# mini_rails/mini_r_spec.rb
# The main leaf
module MiniRSpec
  # Initialize describe leaf and store data in the base object
  def self.describe(title, &block)
    unit = Base.instance
    leaf = DescribeLeaf.new(title)
    leaf.instance_exec(&block)
    unit.ast << leaf
    unit
  end
end

The algorithms of context and it leaves are similar, therefore I implement MiniRSpec::Context module to include it.

# mini_rails/mini_r_spec/context.rb
# NOTE: There is the main logic for describe and it leaves
module MiniRSpec::Context
  # @param described_object [String, Object] Object must respond to method .to_s
  # @return [DescribeLeaf]
  def describe(described_object, &block)
    leaf = DescribeLeaf.new(described_object)
    leaf.instance_exec(&block) if block_given?
    leaf
  end
  alias_method :context, :describe

  # @param described_object [String, Object] Object must respond to method .to_s
  # @return [ItLeaf::Base]
  def it(described_object, &block)
    leaf = ItLeaf::Base.new(described_object)
    leaf.proc = block
    leaf
  end
end

# mini_rails/mini_r_spec/describe_leaf.rb
# NOTE: `describe` leaf
class MiniRSpec::DescribeLeaf
  include Context
  def initialize(title)
    @title = title
    @children = []
  end

  # @described_object [String, Object] Object must respond to method .to_s
  # @return [DescribeLeaf]
  def describe(described_object, &block)
    leaf = super
    @children << leaf
    nil
  end
  # NOTE: Rewrite aliase
  alias_method :context, :describe

  # @described_object [String, Object] Object must respond to method .to_s
  # @return [ItLeaf::Base]
  def it(described_object = '', &block)
    leaf = super
    @children << leaf
    nil
  end
end

# NOTE: `it` leaf
# mini_rails/mini_r_spec/it_leaf/base.rb
class MiniRSpec::ItLeaf::Base
  include Context
  def initialize(title)
    @title = title
    @proc = nil
  end

  def describe(described_object)
   raise 'ERROR: Can not use describe inside "it" block'
  end

  # NOTE: Rewrite aliase
  alias_method :context, :describe
end

The AST is completed. How to run test cases? I had to traverse AST and run each ruby Proc in it leaf.

# mini_rails/mini_r_spec/base.rb
# Singleton class to store test data as AST in @ast variable
class MiniRSpec::Base
  def run_tests
    @ast.each do |node|
    if node.is_a?(ItLeaf::Base)
     node.run_tests
    elsif node.is_a?(DescribeLeaf)
      node.run_tests
    end
  end
end

# mini_rails/mini_r_spec/describe_leaf.rb
# NOTE: `describe` leaf
class MiniRSpec::DescribeLeaf
  # @param context [String]
  def run_tests(context = nil)
    context = [context, title].compact.join(' ')
    children.each do |node|
      if node.is_a?(ItLeaf::Base)
        node.run_tests(context)
      elsif node.is_a?(DescribeLeaf)
        node.run_tests(context)
      end
    end
  end
end

# mini_rails/mini_r_spec/it_leaf/base.rb
# NOTE: `it` leaf
class MiniRSpec::ItLeaf::Base
  # @param context [String]
  def run_tests(context = nil)
    context = [context, title].compact.join(' ')
    return nil if @proc.nil?

    # Clear DB before running the test case
    ::MiniActiveRecord::Base.driver.destroy_database!

    # Run the test case
    instance_exec(&@proc)
    TestManager.instance.add_success(context)
  rescue ::StandardError => e
    TestManager.instance.add_failure(context, e)
  end
end

It works, but there is only core features.

Variables and callbacks

Now I can write and run tests cases but there will be a lot amount of the same code in the test cases. All tests should be DRY, helpers as let, let! and callbacks as before_each help with it. I decided to implement let! and before_each features for the describe leaf to save data in instance variables.

# mini_rails/mini_r_spec/describe_leaf.rb
# NOTE: `describe` leaf
class MiniRSpec::DescribeLeaf   
  def initialize(title)
    # CODE
    @callbacks = [] # Array for before_each callbacks
    @variables = {} # Hash for let! data
  end

  # @param variable_name [String, Symbol]
  def let!(variable_name, &block)
    @variables[variable_name.to_sym] = block
  end

  def before_each(&block)
    @callbacks.push(block)
  end
end

Then I extended run_tests method to collect and pass variables and callbacks to the it block.

# mini_rails/mini_r_spec/describe_leaf.rb
# NOTE: `describe` leaf
class MiniRSpec::DescribeLeaf  
  # @param context [String]
  # @param before_callbacks [Array<Proc>]
  # @param variables [Hash<Symbol, Proc>]
  def run_tests(context = nil, before_callbacks = [], variables = {})
    # CODE
    merged_callbacks = before_callbacks + @callbacks
    merged_variables = variables.merge(@variables)

    children.each do |node|
      if node.is_a?(ItLeaf::Base)
        node.run_tests(context, merged_callbacks, merged_variables)
      elsif node.is_a?(DescribeLeaf)
        node.run_tests(context, merged_callbacks, merged_variables)
      end
    end
  end
end

Further I extended the it leaf to run callbacks and receive data from let! handlers.

# mini_rails/mini_r_spec/it_leaf/base.rb
# NOTE: `it` leaf
class MiniRSpec::ItLeaf::Base
  def initialize(title)
    # CODE
    @variables = {} # Hash for let! data
  end

  # @param context [String]
  # @param before_callbacks [Array<Proc>]
  # @param variables [Hash<Symbol, Proc>]
  def run_tests(context = nil, before_callbacks = [], variables = {})
    # CODE
    # Run all let! blocks
    variables.each do |var_name, proc|
      @variables[var_name] = instance_exec(&proc)
    end

    # Run all before-callbacks
    before_callbacks.each do |callback|
      instance_exec(&callback)
    end

    # Run the test case
    instance_exec(&@proc)
    # CODE
  rescue ::StandardError => e
    # CODE
  end

  def method_missing(message, *args, &block)
    if @variables.key?(message) 
      # let! variables support
      @variables[message]
    else
      super
    end
  end
end

Test matching

Final point is to implement a test matching such as:

expect(1).to eq(1)
expect(1).not_to eq(2)
expect(1).to be_present
expect(true).to be_truthy
expect([1,2,3]).to include(2)

In order to implement it I wrote the MiniRSpec::Matcher as the template method OOP-pattern. Under the hood the code above is just syntax sugar for the code below:

EqMatcher.new(1) == Matcher.new(1)
EqMatcher.new(2) != Matcher.new(1)
BePresentMatcher.new == Matcher.new(1)
EqMatcher.new(true) == Matcher.new(true)
IncludeMatcher.new(2) == Matcher.new([1,2,3])

Source code looks like this:

# mini_rails/mini_r_spec/matchers.rb
class MiniRSpec::Matcher
  def initialize(value = nil)
    @value = value
  end

  def to(matcher)
    matcher == @value
  end

  def not_to(matcher)
    matcher != @value
  end
end

class MiniRSpec::EqMatcher < Matcher
  def ==(new_value)
    a = @value == new_value
    raise MatchError, "'#{new_value}' does not equal '#{@value}'" if a == false
    a
  end

  def !=(new_value)
    a = @value != new_value
    raise MatchError, "'#{new_value}' equals '#{@value}'" if a == false
    a
  end
end

Conclusions

Write something from scratch is fun. The challenge to write a framework was absolutely new experience to me. After working on it I noticed some useful things and whould like to share my thoughts with you.

`class_attribute`

It's very cool feature to share data between class and class instance. In the article and in the source code you see that I often use it to implement some features.

A function wrapper

A usable interface is very important when you write a library. A function wrapper can reduce amount of code and make it easy to write and read. Example for validation module:

module MiniActiveRecord::Validation::ClassMethods
  # A function wrapper
  def validates(field_name, presence: nil, length: {})
    if presence.present?
      validates_presence_of(field_name)
    end
    if length.present?
      validates_length_of(field_name, max: length[:max], min: length[:min])
    end
  end

  def validates_presence_of(field_name)
    # Core function
  end

  def validates_length_of(field_name, max: nil, min: nil)
    # Core function
  end
end

Also ActiveSupport's extract_options! method is also useful to make the interface flexible. You can see below an example for factories. build functions receive factory name, traits and options.

module MiniFactory
  class << self
      # Example of usage: build(:factory_name, :trait1, attr1: ''1)
    #   build(: factory_name, :trait1, :trait2, attr1: '1')
    #   build(: factory_name, attr1: '1') 
    def build(factory_name, *traits_and_opts)
      opts = traits_and_opts.extract_options!
      traits = traits_and_opts.map(&:to_sym)
      Base.instance.build_factory(factory_name, traits, opts)
    end
  end
end

Use recursion to write a flexible inferface

Data in function's argument can be flexible. There is an example for render module below. view_name params can be a string, a symbol and can be without _. In order to implement it easily I used recursion.

module MiniActionView::Render
  # @param view_name [String, Symbol]
  #   Can be: '_header', :header, 'shared/header'
  #   For symbol it adds _ in the beggining of name.
  # @param collection [Array<Object>] each item will be passed as 'item' variable
  # @param locals [Hash<Symbol,Object>] params to passing data as local_variables
  def render_partial(view_name, collection: [], locals: {})
    if view_name.is_a?(Symbol)
      render_partial("_#{view_name}", collection: collection, locals: locals)
    elsif view_name.exclude?('.html.erb')
      render_partial("#{view_name}.html.erb", collection: collection, locals: locals)
    elsif collection.size > 0
      collection.map { |i| render_view(view_name, locals: {item: i}) }.join('')
    else
      render_view(view_name, locals: locals)
    end
  end
end

STI and multi attributes models in Rails

Vladislav Kopylov — Mon, 03 Jan 2022 15:48:54 +0000

Once I had a task to collect data from different landing pages to a database. The task is challenging because each web form from a landing page has different inputs and data. I figured out how to write an elegant solution in a Rails application.

Preparation

First, we have to create a migration to store data in DB.

class CreateLandingForms < ActiveRecord::Migration
  def change
    create_table :landing_forms do |t|
      t.string :type
      t.jsonb :data
      t.timestamps
    end
  end
end

The “type” is an important attribute for STI (single table inheritance) because we will have a few models (one model for each landing page) which use the same table in DB. Rails will automatically keep class name to the attribute.

The “data” is an attribute with JSONB data type. Each model has a unique amount of fields. We will store the information in the attribute as JSON.

Models

The main model looks like that. There is nothing special. Other models will be inherited from the main model.

# app/models/landing_form.rb
# == Schema Information
#
# Table name: landing_forms
#
#  id         :bigint           not null, primary key
#  data       :jsonb
#  type       :string
#  created_at :datetime         not null
#  updated_at :datetime         not null
#
class LandingForm < ApplicationRecord
end

Let’s create models to collect data from different web forms. For instance, from 2 landing pages: Christmas’s landing page and Black Friday’s landing page.

Here is a model for Christmas’s landing page. Attributes are full name, phone number, city, state, address and a gift you would like to receive from Santa. :-) Method store_accessor helps us to collect data to the “data” field and work with it such typical ActiveRecord attributes.

# app/models/landing_forms/christmas.rb
module LandingForms
  class Christmas < LandingForm
    store_accessor :data, :full_name, :phone_number, :city, :state, :address, :gift

    validates :full_name, presence: true
    validates :phone_number, presence: true
    validates :city, presence: true
    validates :state, presence: true
    validates :address, presence: true
    validates :gift, presence: true

    def self.permitted_params
      [:full_name, :phone_number, :city, :state, :address, :gift]
    end
  end
end

The next model - is a model for Black Friday’s landing page. Attributes are first name, second name and email. If there is a requirement that email must be unique, we can add custom validation for email.

# app/models/landing_forms/black_friday.rb
module LandingForms
  class BlackFriday < LandingForm
    store_accessor :data, :first_name, :last_name, :email

    scope :by_email, ->(email) { where(["data->>'email' IN (?)", email]) }

    validates :first_name, presence: true
    validates :last_name, presence: true
    validates :email, presence: true

    validate :unique_email

    def self.permitted_params
      [:first_name, :last_name, :email]
    end

    private

    def unique_email
      return if errors.size.positive?
      return if self.class.where(type: type).by_email(email).where.not(id: id).count.zero?

      errors.add(:email, I18n.t('landing_forms.email_already_taken'))
    end
  end
end

You see there is nothing difficult to describe behaviour. In order to prove that the validation works we will write test cases. Fortunately store_accessor works best with FactoryBot.

# spec/factories/landing_form_factory.rb
FactoryBot.define do
  # factory for one model
  factory :black_friday_form, class: LandingForms::BlackFriday do
    first_name { Faker::Name.first_name }
    last_name { Faker::Name.last_name }
    email { Faker::Internet.email }
  end

  # factory for another model
  factory :christmas_form, class: LandingForms::Christmas do
    full_name { Faker::Name.name_with_middle }
    phone_number { Faker::PhoneNumber.phone_number }
    city { Faker::Address.city }
    state { Faker::Address.state }
    address { Faker::Address.full_address }
    gift { Faker::Hipster.sentence }
  end
end

And here are unit tests.

# spec/models/landing_form_spec.rb
require 'rails_helper'

RSpec.describe LandingForms::Christmas, type: :model do
  let(:item) { build(:christmas_form) }

  it 'works' do
    expect(item.save).to eq(true)
  end
end

RSpec.describe LandingForms::BlackFriday, type: :model do
  let(:item) { build(:black_friday_form) }

  it 'works' do
    expect(item.save).to eq(true)
  end

  describe 'unique email validation' do
    let!(:item1) { create(:black_friday_form) }

    context 'email is not the same' do
      let(:item2) { build(:black_friday_form) }

      it 'is valid' do
        expect(item2.valid?).to eq(true)
        expect(item2.save).to eq(true)
      end
    end

    context 'email is the same' do
      let(:item2) { build(:black_friday_form, email: item1.email) }

      it 'is not valid' do
        expect(item2.valid?).to eq(false)
        expect(item2.errors.attribute_names).to include(:email)
        expect(item2.errors[:email]).to include(I18n.t('landing_forms.email_already_taken'))
      end
    end
  end
end

Controllers

In order to receive data from a client, we write endpoints in rails-router, one endpoint for each controller.

Rails.application.routes.draw do
namespace :api do
    namespace :v1 do
      namespace :landing_forms do
        post :black_friday, to: 'black_friday#create'
        post :christmas, to: 'christmas#create'
      end
    end
  end
end

A controller looks like that. Just one public method create. We don’t need anything more.

# app/controllers/api/v1/landing_forms/black_friday_controller.rb
module Api
  module V1
    module LandingForms
      class BlackFridayController < ApplicationController
        def create
          object = model_class.new(model_params)
          if object.valid? && object.save
            render json: { success: true }
          else
            render json: object.errors, status: :unprocessable_entity
          end
        end

        private

        def model_params
          params.permit(*model_class.permitted_params)
        end

        def model_class
          ::LandingForms::BlackFriday
        end
      end
    end
  end
end

Let's write request test cases for the controller to prove that it works.

# spec/requests/api/v1/landing_forms/black_friday_spec.rb
require 'rails_helper'

RSpec.describe Api::V1::SubscriptionsController, type: :request do
  describe '#create' do
    subject { post '/api/v1/landing_forms/black_friday', params: params, as: :json }

    before { subject }

    context 'email validation' do
      let!(:item1) { create(:black_friday_form) }

      context 'email is unique' do
        let(:params) do
          { first_name: Faker::Name.first_name, last_name: Faker::Name.last_name, email: Faker::Internet.email }
        end

        it 'renders success' do
          expect(response).to have_http_status(:ok)
          expect(JSON.parse(response.body)['success']).to eq(true)
        end
      end

      context 'email is the same' do
        let(:params) do
          { first_name: Faker::Name.first_name, last_name: Faker::Name.last_name, email: item1.email }
        end

        it 'returns errors' do
          expect(response).to have_http_status(:unprocessable_entity)
          json = JSON.parse(response.body)
          expect(json.keys).to eq(['email'])
          expect(json['email']).to include(I18n.t('landing_forms.email_already_taken'))
        end
      end
    end
  end
end

Voilà! It works. Now it’s super easy to collect data from one more web form. We need:

Create a new model and describe all attributes and validations
Create a new endpoint in the route and a controller