Ruby on Rails | rubyhub
Open in Telegram
1 794
Subscribers
-124 hours
-47 days
-630 days
Posts Archive
Repost from Удалов
Давно не было соло — решил записаться без гостя и разобрать то, что вы сами накидали в комментариях и в канале.
Про агентов с полным доступом к инфре после выпуска с Русланом. Про DDD, TDD и зачем это, даже если на собесе не спрашивают. Про vibe coding, тестировщиков как узкое место и спор: ИИ отупляет или просто меняет навыки — как когда появился Google.
Heavy Tech #46
https://youtu.be/SQDQHuZs2rk
Ruby on Rails обошёл Next.js
а Vercel всё ещё немного опережает Cloudflare
n = 3 658 стартапов
Production Results
Что происходит, когда production Rails-приложения переводят с threads на fibers?
На Rage.rb:
— p95 latency ниже в 6x и 10x под нагрузкой
— 0% ошибок
— реальные endpoints и production traffic, без микробенчей
Podlodka #477 – Ruby on Rails Deep Dive
Кирилл Мокевнин – сооснователь онлайн-школы программирования «Хекслет», разработчик с почти двадцатилетним стажем, амбассадор организованного программирования и автор одноимённых YouTube- и Telegram-каналов. Он работал с Ruby on Rails ещё в коммерческой разработке, вокруг Rails строился сам Хекслет, и во многом на рельсах формировался его инженерный опыт.
Rails много раз хоронили, но он почему-то продолжает жить. В него коммитят, вокруг него остаются большие продукты, он по-прежнему очень быстро закрывает типовые веб-задачи и даёт то самое ощущение, что один человек может сделать приложение от и до. Разбираем главные идеи рельсов: convention over configuration, ActiveRecord, миграции, серверную шаблонизацию, jobs, очереди и готовую инфраструктуру.
Отдельно обсуждаем тёмную сторону этой философии: магию, метапрограммирование, динамически сгенерированные методы, колбэки в моделях, before_validation, жирные модели и боль больших проектов. А ещё – Sorbet, Tapioca и то, почему Кирилл со временем стал больше ценить типизацию, кодогенерацию и более «деревянный» код.
Не обходим стороной фронтенд в рельсах: Hotwire, Inertia, React, TypeScript и вечный спор о том, где не писать JavaScript действительно полезно, а где превращается в тупиковую ветку.
Ну и конечно обсуждаем главное: кому Rails вообще нужен сегодня. Почему его рано списывать, в каких продуктах он всё ещё даёт огромную скорость, а где лучше честно выбрать другой стек.
🎧 Слушать выпуск
👀 Смотреть выпуск
👉Предложить себя в подкаст
Repost from Ruby on Rails 8. На русском
Ruby on AI. Дизайн Агента (Часть 1) / AI Harness
👉 https://youtu.be/z9TEJVKP77g
Группа: @pro_ruby_on_rails_ru
Вопросы: @ilia_zykin
❤️ лайк 🔂 репост
Забавно наблюдать, как Ruby on Rails когда-то вдохновлял Laravel, а теперь создатель Rails — David Heinemeier Hansson — выступает на сцене Laravel-ивента.
We are honored to announce David Heinemeier Hansson aka @dhh 🇩🇰, creator of Ruby on Rails, on stage at Laravel Live Denmark 2026. A Dane whose framework inspired a generation of developers comes home to Copenhagen this August. Different framework, same craft.
Repost from Удалов
Прагматичный DDD на Ruby: 350 микросервисов, тесты за 5 минут
https://youtu.be/gqHMT62NqU0
🚞 Rails Security Best Practices: A Comprehensive Guide
Разбор того, что Ruby on Rails защищает «из коробки», а что — нет: встроенная защита от CSRF, работа с cookies и экранирование данных — в отличие от задач на уровне самого приложения, таких как двухфакторная аутентификация (2FA), ведение журналов действий и управление доступом
💻 Вы делаете вайб-кодинг неправильно!!!
Стрим с ru_ruslan, топ-комментатором рубе-сообществ!
После наших вайб-код стримов разнес нас в пух и прах. Говорит, что делаем мы все неправильно. Сегодня покажет практики и свое кунг-фу.
Если почему-то не знаете Руслана? В любом ruby-чатике — первый коммент под постом его. Не верится, что он находит еще время на работу и освоение новых инструментов, но смегодня он докажет обратное.
Вы делаете вайб-кодинг неправильно
Стрим начался, подключаемся https://youtube.com/live/UqVX824JJLs?feature=share
📺Что должен знать каждый backend про N+1, lazy preload и производительность / 💎Евгений Демин
В этом выпуске в гостях Евгений Дёмин — Ruby-разработчик и автор нескольких популярных open source библиотек, которые решают проблемы с базами данных, валидацией и производительностью. Женя начинал как математик в Калининграде, попал на западный рынок почти случайно — друг порекомендовал его британскому рекрутеру, а всё собеседование свелось к фразе «Yes, please» в телефонной трубке.
Тем не менее его взяли.
‼️Анонсируем набор докладов на конференцию в Санкт-Петербурге (примерная дата ~ 6 июня).
Жестких ограничений по темам нет - про Ruby, базы данных, devops и в целом все что можете интересно рассказать. В видео поговорили про доклады и конференции, не стесняйтесь подавать заявку, если вы в чем-то разобрались, это может быть многим интересно.
ПОДАЧА ДОКЛАДА ➡️ https://forms.yandex.ru/u/69b53f6d84227c436538552c/
Питерское (на самом деле глобальное) сообщество Рубистов https://t.me/saintprubycommunity
Repost from N/a
Слой LLM в Rails: проектируем базовый класс
Вчера в комментах показывали ruby_llm-agents, я его посмотрел и выяснил две вещи:
1. гем довольно сильно похож на то, что я придумал;
2. как я мог его пропустить? а так: он вышел в январе, а я занимался этим в октябре, просто долго зрел писать пост 🤷♂️
Я еще почитал и выяснил, что в ruby_llm тоже завезли похожий DSL. Хорошо, что у меня другой, а то бы вы этот пост не читали!
---
Каждый вызов LLM должен быть обернут в отдельный класс, который является наследником базового класса (назовем его `BaseLLMRequest`). Весь бойлерплейт и инструментация находятся базовом классе, а наследники лишь настраивают параметры запроса. Реализвать базовый класс можно так:
class BaseLLMRequest
def call
chat = build_chat
message = build_user_message
# Runner — отдельный класс для выполнения запроса, чтобы отделить транспортный уровень
response = Runner.new(chat:).run_with(message)
transform_response(response.content)
end
private
def build_chat
chat = Chat.create!(model:)
chat = chat.with_instructions(instructions) if instructions
chat = chat.with_schema(output_schema) if output_schema
# Тут можно добавить любые настройки для чата; некоторые шаги могут быть необязательными.
chat
end
# Конфигурация — переопределяется в наследниках
def model = nil
def prompt = ""
def instructions = nil
def output_schema = nil
# здесь мы будем преобразовывать сырой ответ в нечто, удобное для бизнес–слоя
def transform_response(raw) = raw
# хелпер для ERB — о нем поговорим ниже
def eval_erb_template(path, variables)
template = File.read(path)
ERB.new(template, trim_mode: "-").result_with_hash(variables)
end
end
Теперь — пример класса–наследника:
class TicketClassificationLLMRequest < BaseLLMRequest
option :ticket
def model = "gpt-4o-mini"
# можно попробовать схитрить и сделать дефолтную реализацию так, чтобы использовались эти пути и имена
def instructions_path = File.expand_path("./instructions.text.erb", __dir__)
def output_schema_path = File.expand_path("./output_schema.json", __dir__)
def prompt_path = File.expand_path("./prompt.text.erb", __dir__)
# про ERB поговорим ниже
def prompt = eval_erb_template(prompt_path, { body: ticket.body })
# проверяем, что категория — корректная и добавляем больше данных в ответ
def transform_response(raw)
category = raw["category"]
VALID_CATEGORIES.include?(category) ? Success(category:, summary: raw["summary"]) : Failure()
end
end
Почему не DSL (как в вышеупомянутом геме), а просто методы? Всегда можно переехать, но такой подход дает больше гибкости. Например, если захочется запустить A/B–тест на модель, достаточно будет добавить эту логику в реализацию:
def model
if user.ab_tests["best_model"] == "segment_4"
"gpt-5"
else
"gpt-4o"
end
end
Промпты как ERB-шаблоны
Все части промпта и схему я решил держать в файлах (либо строчках прямо в классе, если нужно). Структура примерно такая:
llm_requests/
ticket_classification_llm_request.rb
ticket_classification_llm_request/
instructions.text.erb
output_schema.json
ERB здесь работает так же, как во views: с помощью eval_erb_template мы выполняем подстановку переменных в шаблон.
Отдельно стоит упомянуть разницу между prompt и instructions. Prompt идёт от роли *user*, instructions — от роли *developer*. У провайдеров developer role по идее имеет более высокий приоритет. кроме этого обычно в instructions лежат — правила и формат ответа, в prompt — конкретные данные для обработки.🖼️ The Real-Time Ruby Framework
не масштабируется или уткнулись в потолок?
Каждый раз, когда кто-то говорит: «Rails не масштабируется», сообщество спешит ответить: «Это неправда». Это звучит успокаивающе. Но не работает. Побеждают в спорах не те, кто отрицает исходную точку — а те, кто умеет её принять и переиграть. В следующий раз не спорьте «в лоб». Попробуйте так: - Раньше это было правдой. Но JIT в Ruby многое изменил. - Иногда это правда — но компромиссы всё равно выгоднее, чем у альтернатив.» - Или идите ва-банк: Да, это правда. Пока вы не попробовали Rage.
Repost from Ruby on Rails | rubyclub
💎 Is Ruby not for AI? Why Elixir is better
The problem with using Rails to do it is everything ends up being executed inside of ActiveJobs. Those work fine for simpler web applications, but if you need to boot an agent that runs commands inside a docker container alongside other agents, jobs won't cut it.
The kill feature in Elixir is supervisor trees. I can boot an agent and give it a docker container for its sandbox. If one crashes, Elixir can recover it and it's fine. Can't imagine easily doing that in Rails or Ruby. Scaling & monitoring it doesn't sound like fun either.
Repost from Половнёв—Журнал
Кодислав — AI coding agent в 100 строк на Руби и YandexGPT
В прошлом посте я обещал рассказать, как собрать собственного агента на Руби, если пост наберет 20 классов. Пост набрал 43 класса. Штош.
Так как я пока программист, то и агент будет для программирования. А чтобы доказать то, что я не лох, что я в хорошей форме, я скручу вам вертушечку, мою фирменную покажу это всё скринкастом.
В Ютюбе:
https://www.youtube.com/watch?v=N02VM7DZmJo
В ВК:
https://vkvideo.ru/video-237008052_456239020
P. S. Слабый ищет оправдания, а у сильного они сразу готовы. Поэтому делайте скидку на волнение, запись одним дублем и первый опыт с OBS. Видос лучше смотреть на 2x, чтобы опечатки не так сильно бесили.
P. P. S. Если лень смотреть, идите сразу в репозиторий:
https://github.com/vast/codislav
💻RubyLLM обновился до версии 1.14
Что добавили:
• Генератор Chat UI на Tailwind стилях: через генератор получаете красивое, полностью рабочее AI-чат-приложение
• Генераторы для Rails: агенты, инструменты и схемы
• Провайдеры теперь автоматически регистрируют свои параметры конфигурации
• Большой пакет исправлений: утечки памяти в Faraday, совместимость с MySQL/MariaDB, корректная передача конфигов агентов
Repost from Удалов
Вышел 43-й выпуск Heavy Tech Podcast.
В гостях Иван Шаматов — Ruby-разработчик, инженер-менеджер и организатор питерской Ruby-конференции.
Разговор о том, как в компаниях внедряют ИИ (от автодополнения до генерации кода и ревью), где на самом деле тормозит delivery — и почему узкое место часто не код, а передача задач между людьми. Плюс: как Иван использует LLM в управлении и для контекста по командам, кого сейчас берут на работу и как проходят собеседования, что делать с образованием детей и куда может двигаться мир профессий.
https://youtu.be/plvPpiWfjt0
💻Когда-то веб был реально быстрым
DHH недавно напомнил, что интернет отлично работал ещё до того, как всё начали массово строить на React. Фреймворк Hotwire Turbo, кстати, основан на идее Pjax — её когда-то придумал Крис Ванстрат для GitHub. Смысл был простой: страница обновляется мгновенно, без полной перезагрузки.
Например, в 2013 году страница GitHub могла загрузиться примерно за 67 мс. По нынешним меркам — почти мгновенно.
Есть кейсы, где после перевода checkout-страницы на Turbo конверсия выросла на 20% — просто потому, что страница стала быстрее.
Available now! Telegram Research 2025 — the year's key insights 
