Hacker News Digest

Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

Bruno Sutic разработал Friendly Attributes Pattern для упрощения создания тарифных планов в своем проекте RailsBilling. Вместо громоздких повторяющихся вызовов с множеством атрибутов, он предложил компактный синтаксис с хэшами, который моделирует ментальную модель типичной страницы ценообразования. Новый подход преобразует различные структуры (массивы, хэши, значения) в стандартные атрибуты, используя типы данных для интерпретации: символы - как имена планов, числа - как суммы, ActiveSupport::Duration - как интервалы.

Паттерн работает в различных контекстах: в тестах, в консоли Rails, с методами поиска. Он поддерживает передачу аргументов в любом порядке, что удобно для разных языков, и позволяет использовать как отдельные значения, так и сложные структуры. Friendly Attributes является надмножеством стандартных атрибутов, обеспечивая обратную совместимость. Если подход не нравится, можно продолжать использовать традиционные методы без изменений.

This is...not for me. It follows a big pattern in Ruby/Rails culture where to understand the code, you first have to understand the magic. And, it's never all that obvious where to go to try and understand the magic, because the magic itself has been imported by magic.I once was

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Новая функция http.CrossOriginProtection в Go 1.25 помогает защититься от CSRF, проверяя заголовки Sec-Fetch-Site и Origin. Она блокирует небезопасные запросы (POST, PUT и т.д.) от разных источников. Однако она не защищает от старых браузеров без этих заголовков. Для полной безопасности следует сочетать её с токенами.

• Обсуждение показало, что защита от CSRF через заголовки Origin/Sec-Fetch-Site работает примерно в 95% браузеров, и автор статьи не считает это проблемой.
• Участники обсуждали, что отказ от поддержки старых браузеров — это сознательный выбор, а не упущение, и что в 2025 году оставшиеся 5% в основном представляют собой старые телевизоры, телефоны и прочие устройства, которые не могут быть обновлены.
• Некоторые участники отметили, что даже если бы мы хотели защитить этих пользователей, устаревшие методы вроде проверки Referer или токенов всё ещё не защитят от CSRF, а значит всё равно придётся от них отказаться.
• Была поднята тема, что Rails и другие фреймворки уже давно решили эту проблему, но автор статьи ответил, что не видит в этом необходимости, так как считает, что вся ответственность за безопасность ложится на разработчика, который должен внимательно изучить документацию.

Turbo отслеживает Turbo Streams через два механизма. При отправке форм он перехватывает события submit через слушателя на document, предотвращает стандартную отправку и использует fetch API с заголовком Accept: text/vnd.turbo-stream.html. Это сигнализирует серверу, что можно отвечать Turbo Stream элементами. Сервер, в свою очередь, должен вернуть ответ с Content-Type: text/vnd.turbo-stream.html.

Для обработки ответов Turbo использует слушателя события turbo:before-fetch-response. Этот обработчик проверяет тип содержимого ответа и при совпадении добавляет содержимое в DOM. Когда <turbo-stream> элементы добавляются, они автоматически выполняют одно из семи действий (append, prepend, replace и т.д.). Для обычных fetch-запросов разработчикам нужно самостоятельно добавлять заголовок Accept.

• Turbo Streams становятся менее актуальными, так как фреймворк уже сам по себе использует их по умолчанию; оставляем только для специфичных сценариев вроде уведомлений.
• Подписки на каналы и фреймы полезны для изолированных обновлений, но не стоит переусердствовать с ними в ущерб стандартным паттернам.
• Покупатели из ЮВА сталкиваются с отсутствием покупательского паритета; вопрос о ценах и доступности курса остаётся открытым.
• Сообщество обеспокоено, что чрезмерная рельсовость может оттолкнуть не-Ruby разработчиков, которые сейчас используют Turbo вне Rails.

Rails + SQLite: новые способы уронить прод

SQLite встроен в процесс веб-сервера — нет отдельного демона, портов, сокетов; всё хранится в одном файле. Плюс: пропали ошибки подключения к БД. Минус: файл живёт в контейнере, а контейнеры пересоздают, и данные исчезают.

Правило 1: клади БД в персистентное хранилище (EBS, Fly Volumes, …) и включи снапшоты.

Правило 2: веб, кеш, очередь и джобы по умолчанию пишут в тот же файл. Удобно, но воркеры теперь должны видеть этот файл. Запускай воркеры в том же VM, либо разнеси данные по разным БД и настрой database.yml.

Правило 3: SQLite блокирует всю БД на время записи. Параллельные длинные запросы = таймауты. Держи транзакции короткими, используй PRAGMA journal_mode=WAL, synchronous=NORMAL, busy_timeout=5000.

Правило 4: бекапы. sqlite3 db.sqlite3 ".backup backup.sqlite3" — атомарно, без остановки сервиса. Крути каждый час и перед деплоем.

Плюсы:

• FTS5-индекс из коробки
• Мегабайты вместо гигабайтов RAM
• $14/мес на Fly.io при 1 млн запросов
• Нет Redis, Postgres, S3 — только Rails-контейнер

Итог: SQLite позволяет поднять pet-project за вечер, но требует новых привычек: персистентные диски, WAL, короткие транзакции, общий доступ к файлу. Соблюдай правила — и база не уйдёт в /dev/null.

• Автор статьи утверждает, что его сервис «Feed Your Email» возможен только благодаря SQLite, но не объясняет, почему именно SQLite, а не PostgreSQL/MySQL.
• Многие участники считают SQLite удобным для малонагруженных и внутренних приложений из-за простоты развёртывания и отсутствия отдельного процесса БД.
• Критики отмечают: при росте нагрузки появляются проблемы с бэкапами, масштабированием, единственным писателем и отказоустойчивостью, смывая преимущества.
• Часть разработчиков использует обёртки вроде Litestream, Turso или Cloudflare D1, чтобы добавить репликацию и горизонтальное масштабирование к SQLite.
• В сообществе Rails новый тренд — «по-умолчанию SQLite» для быстрого старта MVP, но опытные пользователи предупреждают о риске «выстрелить себе в ногу» при росте проекта.

Next.js выводит из себя

Наконец-то написал пост: злость лучший мотиватор.
В $COMPANY упал сервис на Next.js, а логов в проде нет. Задача — добавить логирование.

Middleware
Дока обещает: «Middleware выполняется до рендера, удобно для логов».
Пробуем pino + AsyncLocalStorage:

// middleware.ts
export async function middleware(req: NextRequest) {
  LoggerStorage.enterWith(requestLogger());
  logger()?.debug({ url: req.url }, "start");
  return NextResponse.next();
}

Запускаем — логи летят в браузер. Почему? Runtime по умолчанию edge. Меняем на nodejs — в новом проекте работает, в боевом нет.

Страницы и layouts
Пишем в компоненте:

logger()?.info("from page");

Тишина. logger() возвращает null: рендер и middleware живут в разных async-контекстах.

Решение
Передаём requestId через заголовки:

// middleware.ts
const id = crypto.randomUUID();
loggerInstance.child({ requestId: id }).debug("start");
return NextResponse.next({ headers: { "x-request-id": id } });

// page.tsx
const id = headers().get("x-request-id");
loggerInstance.child({ requestId: id }).info("from page");

Итог: чтобы просто логировать, нужно городить костыли через заголовки.

• Пользователи жалуются на игнорирование сотен старых issue, перегруженность абстракциями и постоянные «канареечные» решения, которые не доходят до продакшена.
• Сообщество считает Next.js «самой худшей» технологией: сложно понять, где выполняется код, нельзя цепочкой middleware, а апи-шлюзы выглядят «как будто их писали выпускники буткемпа».
• Разработчики предлагают уходить на Remix, React Router v7, Nuxt, SolidStart, Deno Fresh или даже «чистый HTML/CSS» ради простоты и контроля.
• Представитель Vercel признаёт DX-проблемы и обещает улучшения, но многие уже мигрируют на Vite или Django/Rails/Phoenix.

Разрабатывайте самое простое, что только может работать.
Это правило годится и для исправления багов, и для новых систем.

Многие инженеры мечтают о «идеальной» архитектуре: масштабируемой, распределённой, красивой. Это ошибка. Лучше глубже понять текущую систему и сделать самое простое решение.

Простое может выглядеть скучно
Джуны любят рисовать сложные схемы из кэшей, очередей, прокси. Настоящее мастерство — уметь делать меньше. Великий дизайн выглядит тривиально: «О, задача оказалась простой».
Unicorn и стандартный Rails REST API — примеры: всё нужное достигается очевидными средствами.

Практика
Нужно ограничение частоты запросов в Go-сервисе?

• Вариант 1: Redis + алгоритм «протекающего ведра».
• Вариант 2: счётчики в памяти (теряются при рестарте).
• Вариант 3: включить rate-limit в edge-прокси одной строкой конфига.
  Если последнее покрывает требования — выбирайте его.

Развивайте продукт, начиная с минимума и усложняя только по новым требованиям. Это YAGNI как высший принцип.

Возражения

1. Слякоть из костылей
   Костыль не прост — он добавляет сложности. Настоящее простое решение требует понимания всей системы и часто сложнее придумать.

2. Что такое «просто»?
   Простота — это минимум сущностей, минимум переходов, минимум новых инструментов. Она не всегда очевидна и требует инженерной работы.

3. Масштабирование
   Простое не значит «только сейчас». Unix-сокеты, CGI, файлы — примитивы, на которых построены крупные системы. Если завтра потребуется масштаб, выясните новые факты и добавьте минимально необходимое.

Делайте самое простое, что только может работать — и будете удивлены, как далеко это вас заведёт.

• Участники сходятся в том, что «делай самое простое, что может работать» — полезная эвристика, но не универсальный закон.
• Опытные разработчики подчеркивают: простота ≠ легкость; требует глубокого понимания задачи и контекста.
• На больших системах «простое» быстро ломается из-за edge-case’ов и масштаба, поэтому часто приходится усложнять.
• Частая ошибка — проектировать «на вырост»: реакт, k8s и прочее для сайта из трёх страниц, лишь бы «в портфолио».
• Самый практичный совет: фиксируй реальные требования здесь и сейчас и строй под них, а не под гипотетическое будущее.

• Простота — главное в долгоживущем коде: понятность и уверенность при изменениях.
• Программы должны быть «одноразовыми», как Кенни, а не «неубиваемыми», как Терминатор.
• Laravel начинался как хобби на PHP 5.3 и вырос до 70 человек; Тейлор всё ещё единственный куратор ядра.
• Первым коммерческим продуктом стал Forge — решение собственной боли.
• Не ломай обратную совместимость без крайней нужды; «умники» всегда уходят, а их хитрости остаются.
• Лучшие проекты — те, кто не изобретает велосипеды и следует конвенциям.
• Споры закрываются сравнением реального кода: «покажи, как будет выглядеть».
• Фасады остаются популярнее DI, но Laravel постепенно добавляет типы и статический анализ.
• Культура тестирования изменилась после курса Adam Wathan.
• Сейчас задача — передать ответственность команде и оставаться интересным.

• Участники обсуждают, что Laravel учит «не писать код как Laravel»: пример — баг в cache tagging, который просто убрали из документации.
• Поддержка старых версий Laravel (3–4) описывается как кошмар, требующий полного переписывания, тогда как Rails и Symfony позволяют плавные апгрейды.
• Сообщества Laravel, Symfony, Drupal и WordPress различаются культурно: Laravel ориентирован на быстрый MVP и продажу продуктов, Symfony — на стандарты и долгосрочную поддержку.
• Несколько человек жалуются на плохое качество аудио и просят поп-фильтр.

Как RubyGems.org защищает инфраструктуру сообщества

RubyGems.org применяет многослойную защиту:

1. Автоматика – каждый gem сканируется статическими и динамическими анализаторами (инструменты Mend.io, созданные мейнтейнером Maciej Mensfeld).
2. Оценка риска – высоко-рисковые пакеты переходят на ручную проверку.
3. Ретро-скан – старые версии перепроверяются при улучшении детекторов.
4. Внешние источники – данные от партнёров и других реестров.
   Таким образом 70–80 % вредоносных пакетов ловят до публикации.

Что происходит после флага
Инженер безопасности подтверждает вредоносность (≈ 5 % оказываются ложными срабатываниями), затем gem удаляется, действия логируются, а похожие имена блокируются.

Инцидент Socket.dev

• 20 июля 2025 – система отметила подозрительные гемы, подтверждена кража учётных данных.
• 23–28 июля – удалены почти все пакеты и аккаунты.
• 7 августа – после публикации Socket.dev удалили ещё 16 связанных гемов.
  Всего убрали все пакеты злоумышленника; популярные библиотеки не пострадали.

Сообщество
Сообщайте о проблемах: security@rubygems.org или Slack Bundler. Команда быстро реагирует и благодарит за помощь.

Реальность безопасности цепочки поставок
В среднем еженедельно удаляется один вредоносный или спам-пакет. Работа ресурсоёмка и держится на спонсорах (Mend.io, Alpha-Omega) и волонтёрах. Поддержите RubyGems через RubyGems Supporter Program.

Инцидент показал: системы сработали, угроза была локализована. Безопасность OSS – общее дело.

• Один из мейнтейнеров gem-ов сознательно обходит MFA-ограничения RubyGems, чтобы казаться «ненадёжным» и избежать ответственности.
• Участники хвалят Ruby/Rails как «скучный», но надёжный и продуктивный инструмент, противоположный эншиттификации.
• Критикуют отсутствие обязательной подписи гемов и вспоминают, что старая система подписей так и не прижилась из-за нехватки инфраструктуры.
• Мейнтейнер unicorn считается эксцентричным: отказывается от JavaScript и GitHub, а в README сам проект называют «нанёсшим вред экосистеме».
• Сообщество обсуждает, что отсутствие коммерческого давления помогает Rails оставаться стабильным и «не-эншиттифицированным».

Tidewave Web – агент для Rails и Phoenix, работающий прямо в браузере.
Он видит текущее состояние UI, знает структуру проекта и выполняет код в вашем окружении без переключений между инструментами.

Основное

• Общий контекст – кликните по элементу, скажите «добавь кнопку экспорта CSV»; Tidewave сам найдёт шаблон, контроллер и модель.
• Глубокая интеграция – запросы к БД, логи, документация, тесты в браузере.
• Установка – добавьте gem/пакет, откройте /tidewave, подключите GitHub Copilot или Anthropic.
• Цена – 20 сообщений в месяц бесплатно; Tidewave Pro – $10/мес.

Ограничения

• Лучше всего работает с полноценными Rails/Phoenix.
• React/Vue пока не поддерживаются (в планах).
• Django, Flask, Next.js – в листе ожидания.

Планы

TODO-списки, суб-агенты, React-поддержка.
Присоединяйтесь к Discord или форме ожидания.

• Tidewave — это инструмент для «живого» редактирования Phoenix/Rails-приложений прямо в браузере: LLM видит DOM, шаблоны, тесты и может менять код на лету.
• Следующие шаги: React-интеграция, затем Python/JS-фреймворки; уже можно записаться в wait-list.
• Часть пользователей в восторге («не мог мечтать о таком»), другие не понимают преимущества перед Claude Code или MCP-серверами.
• Главный плюс, по словам Jose Valim — глубокая связь с конкретным фреймворком: LLM точно знает, какой шаблон сгенерировал элемент, и может запускать код без угадывания.
• Платная модель: используются ваши ключи Copilot/Anthropic, но после лимита нужно платить Tidewave (часть трафика идёт через их сервер).
• Пока нет поддержки локальных LLM (Ollama) и HTTPS-проблемы у некоторых команд; Jose просит писать в Discord для отладки.

Почему в 2025 году мы всё ещё пишем на Ruby

Стартуя с Lago, мы выбрали Ruby on Rails — у команды был десятилетний опыт, и это был самый быстрый путь к рабочему API. Сегодня система обрабатывает миллионы вызовов в день, пережила множество обновлений Ruby/Rails, и, если бы начинали заново, выбор остался бы тем же.

Скорость как главное преимущество
Rails больше не «тренд» для стартапов, но его используют Shopify, GitHub, GitLab — зрелые компании, которым важна надёжность и скорость разработки. Мы взяли Rails в API-only режиме: без лишнего middleware и рендеринга, но с миграциями, валидациями, Active Record и фоновыми задачами. Это позволило тратить время на продукт, а не на костыли.

Масштабируемость
Rails не масштабируется? Это проблема архитектуры, а не фреймворка.

• Rails 8 упрощает деплой без PaaS.
• Redis + Sidekiq проверен временем.
• Ruby Fibers добавляют асинхронность.
• Puma, автомасштабирование и кеширование справляются с нагрузкой.

Недостатки, с которыми живём

• Производительность и память: ошибки дорого обходятся.
• GIL CRuby: один поток Ruby-кода за раз, поэтому тяжёлые задачи уходят в Go/Rust.
• «Магия» Rails: избегаем лишних гемов и пишем максимально явный код.

Все языки компромиссы; мы выбрали Rails, потому что знаем его настолько хорошо, что умеем обходить ограничения и получать максимум скорости разработки.

• Участники жалуются на рутину вокруг JS/TS-стека: тройное дублирование типов, самописная интеграция auth и прочие «reinventing wheels».
• Многие называют Rails «скучным, но рабочим» инструментом, который до сих пор быстро даёт полный вертикал функционала без бойлерплейта.
• Популярность Rails страдает из-за ассоциаций с «устаревшей» эпохой 10-летней давности и отсутствия хайпа, хотя кодовая база активно развивается (YJIT, ZJIT).
• На практике Rails используется для бизнес-логики и API, а Go/Rust — для I/O- или CPU-ёмких задач; Shopify и GitHub живут по такой же схеме.
• Некоторые мечтают о «Rails на другом языке» (Clojure, Gleam) или ждут, что AI сделает быстрые языки такими же удобными, как Ruby.

rails_charts — гем для Rails, строит графики через Apache eCharts.
Поддерживает Bar, Line, Pie, Scatter, Radar, Candlestick, Heatmap, Treemap, Funnel, Gauge, Tree, Sunburst, Sankey, Boxplot, Parallel, Graph, Liquidfill.

Установка

# Gemfile
gem "rails_charts"

Быстрый старт

<%= line_chart User.group_by_day(:created_at).count %>
<%= bar_chart Order.group(:status).count %>
<%= pie_chart Product.group(:category).sum(:price) %>

Настройка

# config/initializers/rails_charts.rb
RailsCharts.configure do |config|
  config.height = 400
  config.width  = '100%'
  config.theme  = 'dark' # light | dark
end

Примеры

• Line

<%= line_chart(
      User.group_by_month(:created_at).count,
      title: 'Новые пользователи',
      xtitle: 'Месяц',
      ytitle: 'Кол-во'
    ) %>

• Candlestick

<%= candlestick_chart(
      Stock.pluck(:date, :open, :close, :low, :high),
      title: 'Цены акций'
    ) %>

• Heatmap

<%= heatmap_chart(
      Visit.group(:day_of_week, :hour).count,
      title: 'Посещения по часам'
    ) %>

Форматы данных

• Hash
• Array
• ActiveRecord::Relation

Доп. опции

• height, width, colors, library (любые параметры eCharts)
• theme: 'dark' — встроенные темы
• defer: true — отложенная загрузка

Лицензия

MIT

• Gem вдохновлён Chartkick, но добавляет недостающие типы диаграмм и больше кастомизации.
• Пользователи отмечают «календарную» диаграмму как интересную, интересуются настройкой цветов и тултипов.
• Если нужны новые типы графиков, библиотека выглядит достойной альтернативой Chartkick.