Hacker News Digest

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

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

Smalltalk оказал значительное влияние на Ruby, хотя его синтаксис практически не перешёл в Ruby. Основное влияние проявилось в объектно-ориентированных принципах, особенно в идее, что все данные являются частью объектной системы. В отличие от Perl, автор статьи работал с Smalltalk несколько лет и считает его одним из любимых языков, хотя вряд ли будет использовать его снова.

Smalltalk возник в Xerox PARC, той же команде, что создала графический интерфейс, Ethernet и лазерный принтер. В 80-90-х годах Smalltalk был коммерческим продуктом (ObjectWorks/VisualWorks), широко использовался в авиационной промышленности и для проектов, лёгших в основу экстремального программирования. В 1995 году бывшие сотрудники Xerox PARC в Apple выпустили Squeak — открытую реализацию Smalltalk, написанную в основном на самом себе, что обеспечило её лёгкую переносимость. В отличие от большинства современных языков, Smalltalk развивался независимо от Unix/C, представляя собой собственную операционную систему с уникальным синтаксисом и интегрированной средой разработки.

• Smalltalk-80 и его наследие: образ системы (image) как способ распространения состояния, но его нет в современных системах, что делает Smalltalk-80 уникальным.
• Проблема в том, что Smalltalk-80 не имеет синтаксиса, который бы соответствовал современным ожиданиям, и это делает его непривлекательным для новых разработчиков.
• Ruby унаследовал объектную модель Smalltalk, но не его среду разработки, что делает Smalltalk-80 уникальным в своем роде.
• Сообщество Smalltalk активно разрабатывает Pharo и другие современные реализации, но они не могут конкурировать с уже устоявшимися языками, потому что не имеют большой экосистемы.
• Проект, который начинал как Smalltalk-80, теперь может быть выжившимся только как встроенный язык в некоторых проприетарных системах.

Разработчик Ruby-гема Karafka столкнулся с редким, но критическим багом, когда 2700 идентичных ошибок NoMethodError: undefined method 'default' for an instance of String обрушили систему. Ошибка возникала при доступе к elem[:partition] в FFI::Struct, хотя код нигде не использовал метод #default, характерный для Hash.

Исследование показало, что проблема в версиях FFI ниже 1.17.0, где отсутствуют write-барьеры, позволяющие сборщику мусора Ruby освобождать внутренние Hash-объекты. После освобождения память могла перераспределяться под другие объекты, например, строки. Баг проявляется с вероятностью "один к миллиону", но катастрофичен по последствиям. Пользователи использовали Alpine Linux с musl libc, что могло усугубить ситуацию из-за особенностей компиляции и выравнивания структур.

• Обсуждение выявило, что причиной проблемы была давно исправленная ошибка в ffi, а не в Ruby или в коде клиента.
• Участники спора оспаривают, стоит ли считать статью «LLM-шлаком» из-за плохого стиля, даже если сама техническая информация в ней точна.
• Некоторые участники считают, что стиль может быть вызван тем, что автор предпочитает кодить, а не писать, и что технически важная информация была доставлена.
• Другие участники спора отмечают, что статья была полезна и что важно сосредоточиться на техническом содержании, а не на стиле написания.

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

Автор столкнулся с загадкой в Nix: имея бинарник Ruby, он не мог найти соответствующий .drv файл, хотя база данных и кэш NixOS указывали на его существование. Команда nix-store --query выдавала ошибку, а файл отсутствовал в системе, хотя nix derivation show находил совершенно другой .drv файл для того же бинарника. Это противоречило его пониманию работы Nix.

Ключ к разгадке — "fixed-output derivations" (FOD). Автор демонстрирует, что изменения в FOD (даже добавление мусорных атрибутов) изменяют путь самого .drv файла, но не затрагивают выходной путь (/nix/store/...). Это свойство "modulo" означает, что выходные пути зависят только от содержимого, а не от метаданных. В результате для одного бинарника может существовать несколько .drv файлов с разными хэшами, что объясняет парадокс: кэш NixOS указывает на один .drv, а nix derivation show находит другой, но оба ведут к одному и тому же выходному пути.

• Проблема deriver в Nix — это давняя проблема, которая не решается, потому что она не может обеспечить трассируемость от вывода к исходному выражению, что и было первоначальной целью.
• Пользователи сталкиваются с путаницей, когда кэш бинарников не совпадает с локальной оценкой, что приводит к непониманию и неэффективному использованию кэша.
• Появление CA-derivations и фиксированных выводов (fixed-output derivations) усугубляет ситуацию, делая проблему более заметной, но не решает ее.
• Сообщество обсуждает, что необходимо переписать Nix с нуля, чтобы устранить такие архитектурные проблемы, включая проблему deriver.
• Некоторые участники обсуждения подчеркивают, что Guix может быть альтернативой, но его недостаток в количестве пакетов делает его менее привлекательным.

Автор экспериментирует с созданием простого брокера сообщений, используя только два UNIX сигнала вместо сложных систем вроде Kafka. Он объясняет, что сигналы обычно применяются для управления процессами, но предлагает использовать их для обмена сообщениями. Автор рассматривает различные формы IPC в UNIX, включая каналы, сокеты и файлы, а затем фокусируется на сигналах SIGUSR1 и SIGUSR2, которые являются пользовательскими и могут использоваться для собственных целей.

Основная идея заключается в представлении сообщений как последовательности битов, где каждый бит кодируется соответствующим сигналом (0 - один сигнал, 1 - другой). Это позволяет передавать данные между процессами, используя минимальные системные ресурсы. Автор демонстрирует, как можно "взломать" стандартное поведение сигналов для создания эффективной системы обмена сообщениями, опираясь на двоичное представление данных и возможность перехвата сигналов в коде на Ruby.

• Обсуждение показало, что статья вызвала бурную реакцию: от восторга до критики за clickbait-заголовок и «техническую» неточность.
• Комментаторы подчеркнули, что UNIX-сигналы не предназначены для передачи данных, не гарантируют очередность и могут терять сигналы при конкурентном доступе.
• Было отмечено, что вместо сигналов можно использовать уже готовые механизмы, такие как POSIX message queues.
• Некоторые отметили, что статья может быть интересна как учебный материал, но не как руководство к действию.
• В итоге, обсуждение показало, что читатели ожидают более честных и точных заголовков и отсутствия сенсационализма, даже в контексте развлекательных экспериментов.

Команда Ruby во главе с Матцом берёт под свой контроль развитие RubyGems и Bundler, которые до сих пор управлялись независимо, хотя и являются ключевыми компонентами экосистемы Ruby. Это обеспечит долгосрочную стабильность и единство развития. Все существующие лицензии и права остаются в силе, включая авторские права контрибьюторов. Процесс остаётся открытым для сообщества, и разработка продолжится в тесном сотрудничестве с Ruby Central.

Этот шаг укрепляет инфраструктуру Ruby, объединяя ключевые инструменты под одной крышей, что обещает более согласованное и эффективное будущее для экосистемы.

• Ruby Core под руководством Matz официально взял на себя ответственность за RubyGems и Bundler, что стало возможным благодаря тому, что Ruby Central передала им контроль над этими проектами.
• Это решение было воспринято как консенсус в сообществе, поскольку Matz и Ruby Core пользуются большим уважением в сообществе.
• Тем не менее, некоторые участники обсуждения выразили обеспокоенность тем, что не было ясно, как именно произошла передача контроля над проектами, и почему это произошло.
• Некоторые участники также выразили обеспокоенность по поводу того, что Ruby Central может не иметь достаточного контроля над проектами, которые они, по сути, контролируют.
• В целом, однако, большинство участников обсуждения выразили облегчение по поводу того, что теперь Ruby будет иметь более централизованное и стабильное управление, и что Matz и Ruby Core будут обеспечивать надежное и устойчивое будущее для Ruby.

Ruby блока — это фундаментальная концепция, делающая язык выразительным и читаемым. Автор подчеркивает, что даже конструкции вроде it в RSpec являются методами с блоками, что открывает новые горизонты понимания языка. Блоки позволяют создавать мини-языки, расширяя встроенные типы — например, добавляя методы к Integer для создания цепочек вроде 30.minutes.from_now.

Применение блоков разнообразно: от управления ресурсами (как в File.open) до создания DSL. В отличие от Python, где управление ресурсами требует специального ключевого слова with, в Ruby это делается через методы, принимающие блоки. Автор демонстрирует, как можно создать систему управления задачами с помощью блоков, показывая их гибкость и мощь. Понимание этой концепции, по мнению автора, ключ к по-настоящему глубокому пониманию Ruby.

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

Свободное программное обеспечение не победило, несмотря на то, что многие популярные технологии построены на нём. Хотя открытое ПО повсеместно используется в разработке (Linux, Ruby, GitHub), пользователи часто не осознают, что они используют свободное ПО. Это создаёт иллюзию, что открытое ПО "победило", хотя на самом деле проприетарное ПО доминирует в потребительских устройствах.

Например, хотя существуют открытые альтернативы для 3D-печати, игр и даже смартфонов (Librem 5), они остаются нишевыми. В отличие от этого, проприетарные технологии доминируют в потребительской электронике: смартфонах, телевизорах, автомобилях и других устройствах, контролирующих повседневную жизнь.

Это проблема, потому что программное обеспечение "поглощает мир" — всё больше аспектов жизни контролируются кодом. Если этот код проприетарный, пользователи теряют контроль над своими устройствами. Например, модемы для сотовых сетей часто содержат проприетарную прошивку, что затрудняет создание открытых альтернатив (как в случае с Librem 5).

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

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

Ruby Central сообщила о «событии безопасности» в RubyGems.org, но в действительности оно оказалось конфликтом между организацией и бывшим оператором Андре Арко, который вёл службу более 10 лет. Ruby Central утверждает, что он «не имел доступа» к продакшену, но не предоставляет никаких доказательств. Арко же утверждает, что у него оставался доступ к AWS и логам, и что он не мог бы их использовать без ведома. Он также утверждает, что его удалили из организации без объяснений, и что команда не отвечает на его письма. Он также утверждает, что Ruby Central не отвечает на его письма и не предоставляет никакой информации о «безопасности» RubyGems.

• В обсуждении поднимается вопрос о том, как именно было доведено до сведения Арко, что его доступ к продакшену отозван, и какие именно обстоятельства привели к этому решению.
• Участники обсуждения выражают обеспокоенность тем, что новые мейнтейнеры, возможно, не готовы обеспечить безопасность и надежность сервиса.
• Также поднимается вопрос о том, что, возможно, вся эта ситуация имеет большее отношение к политике, чем к техническим аспектам.

Краткий пересказ

30 сентября 2025 года бывший сотрудник Ruby Central Андре Арко сообщил, что у него остался доступ к продакшен-среде RubyGems.org. Почти одновременно блогер Джоэл Дрейпер опубликовал скриншоты, подтверждающие это. Внутреннее расследование показало, что 19 сентября неизвестный злоумышленник сменил пароль root-аккаунта AWS и в течение 11 дней имел возможность администрировать инфраструктуру. В результате Ruby Central отозвала все устаревшие ключи доступа, включила MFA для всех живых аккаунтов и перевела проект на изолированный AWS-аккаунт под единоличным контролем Ruby Central.

• Ruby Central обвиняет бывшего мейнтейнера Andre Arko в том, что он, будучи уволенным, сохранил доступ к корневой учетной записи AWS и изменил пароль, что фактически блокирует организацию от доступа к собственной инфраструктуре.
• Сообщение Ruby Central подчеркивает, что не было никаких доказательств компрометации, но не упоминает о том, что не было никаких доказательств и того, что доступа не было.
• Сообщение Ruby Central не упоминает о том, что они не отозвали доступа к корневой учетной записи, не изменили пароль и не отключили MFA, что, как утверждает Arko, оставляет сервис уязвимым для "незаконного доступа и потенциального утечки данных".
• Arko утверждает, что он не имел доступа к логам доступа, и что Ruby Central не предоставила никаких доказательств того, что кто-то еще имел доступ к этим логам.
• Обсуждение также затрагивает вопрос о том, каким образом Ruby Central может гарантировать, что никакие PII не была скомпрометирована, если они не могут доказать, что никто не имел доступа к логам доступа.

Представлен gem.coop — новый сервер для хранения гемов в экосистеме Ruby, созданный бывшими сопровождающими RubyGems.org. Он предлагает быстрый и простой хостинг, совместимый с Bundler, но оптимизированный для будущего. Все гемы с RubyGems.org доступны в реальном времени, а для использования достаточно заменить источник в Gemfile на https://gem.coop.

Управление проектом организовано по модели Homebrew при поддержке Mike McQuaid, с открытым участием сообщества. Цели — прозрачность, устойчивость и безопасность при общедоступном хостинге. Запуск включает поддержку установки публичных гемов, с планами по дальнейшему улучшению.

• Создана новая альтернативная платформа для пакетов Ruby (gem.coop) из-за конфликта между прежними сопровождающими RubyGems и Ruby Central.
• Обсуждаются технические и организационные аспекты форка: финансирование, необходимость подписи кода, доверие к сопровождающим и проблемы с доступностью из-за домена .coop.
• Часть сообщества поддерживает форк как способ сохранить независимость, другие видят в нём ненужное дробление экосистемы.
• Поднимаются вопросы о мотивах создания форка: является ли это реакцией на политические разногласия или стремлением улучшить техническую инфраструктуру.
• Проводятся параллели с другими инцидентами в open-source (например, переход с Freenode на Libera Chat).

Универсальный раннер и умный REPL на Rust, который автоматически определяет язык программирования по расширению файла или shebang и выполняет код без предварительной настройки. Поддерживает Python, JavaScript, Ruby, Go и другие популярные языки, экономя время на переключении между средами.

Инструмент предлагает интерактивный режим с подсветкой синтаксиса и историей команд, а также пакетную обработку файлов. Ключевое преимущество — кроссплатформенность и минимальные зависимости, поскольку написан на Rust. Практический бонус: можно быстро тестировать сниппеты, не покидая терминал.

• Автор представил инструмент run как унифицированный REPL для множества языков, позволяющий выполнять код разных языков одной командой без переключения между отдельными REPL.
• Обсуждаются технические детали и сравнение с существующими инструментами: шебанг-строка, задачами just, магическими командами IPython/Jupyter и возможностью запуска скриптов через Bash.
• Уточняется классификация языков (Swift, Kotlin) как компилируемых или интерпретируемых в контексте работы инструмента.
• Поднимается вопрос о мотивации создания инструмента и терминологии ("polyglot"), а также простоте добавления поддержки новых языков через реализацию trait на Rust.
• Автор поясняет, что инструмент — это эксперимент новичка в Rust, а не замена существующим решениям.

Автор перевел свой блог с Racket на Lua, чтобы снизить сложность и обеспечить долгосрочную стабильность. Основная причина — разочарование в быстро меняющихся экосистемах вроде JavaScript и Ruby, где постоянные обновления и ломающие изменения усложняют поддержку. Lua привлек медленным развитием: между версиями 5.1 (2006) и 5.4 (2020) различия минимальны, а язык требует лишь компилятора C89.

Блог работает по старинке — через CGI-скрипты, с SQLite в качестве базы и шаблонизацией Mustache. Несмотря на кажущуюся архаичность, автор ценит простоту, минимальное количество зависимостей (около десяти) и возможность писать собственные легковесные библиотеки. Ключевой вывод: блог — это пространство для экспериментов, где можно отказаться от модных инструментов в пользу того, что действительно работает и приносит удовольствие.

• Предложение возродить создание собственных движков для блогов как учебного проекта для инженеров из-за его низкого риска и возможностей для экспериментов.
• Обсуждение выбора Lua как стабильного и минималистичного языка для веб-разработки, несмотря на его недостатки (1-based индексация, разрыв между версиями, мало стандартных библиотек).
• Критика сложности современных стеков для блогов и аргументы в пользу простых решений: статические генераторы (Hugo), чистый HTML или минимальные скрипты (Python, Lua).
• Упоминание альтернативных технологий и подходов: Redbean, Perl, Caddy, XSLT, Web Components, Fennel, OpenResty и другие.
• Подчёркивание важности личного выбора, удовольствия от процесса и независимости от внешних сервисов при создании блога.

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

Ключевые особенности включают многоканальные пайпы (multipipes) для связи команд с несколькими входами и выходами, блоки {{ ... }} для асинхронного выполнения процессов и хранение значений (stored values) для обмена данными между произвольными узлами графа. Примеры использования охватывают бенчмарки сжатия, анализ кода, поиск дубликатов и обработку научных данных, демонстрируя гибкость подхода.

• Идея Dgsh оценивается как устаревшая по синтаксису, но перспективная для современных оболочек вроде nushell и elvish.
• Обсуждаются преимущества представления конвейеров данных в виде направленного ациклического графа (DAG) перед линейными пайплайнами.
• Сравнивается удобство Dgsh для создания конвейеров с написанием аналогичных задач на Python, Ruby или в чистом bash.
• Отмечается сложность работы с пайпами и процессами в Python по сравнению с shell-инструментами.
• Упоминаются альтернативные инструменты, такие как Murex, и фреймворки для оркестрации, например Apache Airflow.

Автор выражает сомнения в однозначности ситуации вокруг конфликта в RubyGems, подчёркивая, что публичная дискуссия сильно упрощена и сводится к нарративу «альтруисты против корпораций», хотя реальность сложнее. Он указывает на давний неразрешённый конфликт между сторонами, где одна активно высказывается публично, а другая хранит молчание, что оставляет рядовых разработчиков в неведении и тревоге.

Ключевая проблема — запутанное управление экосистемой Ruby, разделённое между разными группами: разработчиками языка Ruby, инструментами RubyGems/Bundler и хостингом RubyGems.org. Исторически эти части развивались отдельно, а recentние слияния (например, поглощение Ruby Together Ruby Central в 2022 году) усугубили неразбериху в правах доступа и ответственности, что теперь вылилось в публичный кризис доверия.

• Обсуждение касается конфликта вокруг RubyGems и Ruby Central, где ключевой фигурой является André Arko, чье поведение и профессиональные действия ставятся под сомнение.
• Участники отмечают предвзятость и неоднозначность представленных точек зрения, включая мнение Джастина Сёрлса, который, хотя и считается авторитетом, может быть необъективен из-за связей с Shopify.
• Поднимается вопрос финансирования open-source: должна ли работа оплачиваться пропорционально вкладу, и как действия спонсоров (как в случае с Shopify) влияют на проекты.
• Обсуждаются юридические и этические аспекты, включая обвинения в плагиате кода и потенциальные судебные разбирательства, что заставляет многих участников избегать публичных комментариев.
• В целом, дискуссия сводится к необходимости прозрачности и добросовестности со всех сторон для разрешения конфликта и обеспечения устойчивости open-source проектов.

Разработчики сталкиваются с хаосом при отладке LLM-агентов в продакшене из-за фрагментации стандартов observability. Например, OpenAI предлагает детальные трейсы, но они привязаны к её фреймворку и не позволяют фильтровать отдельные спаны. New Relic поддерживает OpenTelemetry, но интерфейс громоздок для оперативного дебаггинга. Phoenix с OpenInference даёт богатые AI-специфичные спаны, но не полностью совместим с OpenTelemetry и не имеет SDK для Ruby, что критично для таких проектов, как Chatwoot.

Ключевая проблема — противостояние универсального OpenTelemetry (широкая поддержка языков, но базовые типы спанов) и специализированного OpenInference (богатые AI-типы, но слабая экосистема). OpenInference лишь поверхностно совместим с OpenTelemetry, приводя к «unknown» спанам при прямом использовании. Это вынуждает команды выбирать между созданием кастомных SDK, потерей контекста или сменой стека, замедляя разработку. OpenTelemetry остаётся прагматичным выбором из-за зрелости и кросс-языковой поддержки, но требует расширения семантики под AI-workflow.

• Разработка систем наблюдения (observability) для многозадачных LLM-агентов, включая метрики сложности задач и успешности выполнения.
• Обсуждение стандартов и инструментов (OpenTelemetry, Phoenix, Clickhouse) для отслеживания семантических ошибок и трассировки выполнения агентов.
• Критика подхода к оценке через ИИ из-за проблемы "курицы и яйца" и предложения использовать стандартные системы мониторинга.
• Вопросы о практическом применении длинных промптов не-техническими пользователями и динамической маршрутизации в агентах.
• Дискуссия о необходимости совмещения стандартных решений (реляционные БД) с OpenTelemetry для богатой семантики в распределённых системах.

Автор, известный как «парень из Bundler», рассказывает о 15-летней истории проекта, который он помогал развивать с 2010 года. Изначально созданный Yehuda и Carl, Bundler быстро стал стандартом управления зависимостями в Ruby, сохранив свою структуру до версии 2.7.2. После ухода основателей автор взял на себя ведущую роль в поддержке, сотрудничая с Terence Lee и позже основав Ruby Together для финансирования разработки.

Сейчас Ruby Central заявляет права на владение названием Bundler, что противоречит духу сообщества. В ответ автор зарегистрировал товарный знак, чтобы защитить репутацию проекта и его maintainers, подчеркивая, что код остаётся под MIT-лицензией, а название принадлежит сообществу. Ключевая цель — обеспечить, чтобы решения по проекту принимались самими пользователями и разработчиками, а не одной организацией.

• Финансирование Ruby Central от спонсоров вроде Shopify было условием захвата контроля над Bundler и RubyGems, что привело к корпоративному захвату инфраструктуры.
• В ответ на это был зарегистрирован товарный знак Bundler, чтобы предотвратить захват и передать его под управление нового, действительно сообщественного органа.
• Ключевой риск — потеря давних мейнтейнеров, раскол сообщества и форк ключевой инфраструктуры, что создаст хаос.
• Сообщество ожидает ответа от Ruby Central, включая возобновление запланированного Zoom-звонка, но пока ситуация в подвешенном состоянии.
• Под вопросом юридическая сила товарного знака, так как его долгое отсутствие enforcement может означать отказ от прав или генерализацию.

Ruby Central применила подход «deus ex machina», в одностороннем порядке взяв под контроль всю GitHub-организацию RubyGems — ресурс, исторически принадлежавший мейнтейнерам. Они оправдывали это необходимостью нейтрализовать «опасных операторов», но использовали ситуацию для удаления ключевых участников из проектов, включая RubyGems, Bundler и RubyGems.org, и присвоения прав собственности. Shopify, главный спонсор Ruby Central, оказался вовлечён в этот процесс, что вызвало вопросы о согласованности действий с интересами сообщества.

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

• Ruby Central отменила запланированную встречу с сообществом, что вызвало недовольство.
• Shopify, используя финансовое давление на испытывающий нехватку средств Ruby Central, добилась контроля над ключевыми репозиториями (Bundler, RubyGems).
• Члены сообщества обвиняют Ruby Central в непрозрачном процессе принятия решений и отсутствии коммуникации.
• Противоречие также связано с реакцией на доклад о новом инструменте rv и последующей потерей спонсорства.
• Обсуждаются проблемы централизации управления в open-source и утраты первоначальных ценностей сообщества.

Ruby Central, испытывающая финансовые трудности после потери спонсорства Sidekiq ($250 тыс. в год), по требованию Shopify взяла под контроль ключевые проекты Ruby-сообщества — Bundler и RubyGems — без согласия их многолетних сопровождающих. Shopify пригрозила отозвать финансирование, если Ruby Central не обеспечит полный контроль над репозиториями и правами на gems, что привело к принудительному изменению прав доступа и исключению ведущих разработчиков, включая Андре Арко с 10-летним стажем.

Этот захват был преднамеренным: Shopify заранее организовала дежурство для замены прежних сопровождающих, а совет Ruby Central проигнорировал предупреждения о незаконности действий и альтернативы в виде форков. Инцидент подчеркивает риски зависимости open-source от корпоративного финансирования, где сообщество теряет автономию под давлением спонсоров.

• Sidekiq прекратил спонсорскую поддержку Ruby Central на $250 тыс. в год из-за участия DHH в RailsConf 2025, что вызвало споры о его политических взглядах.
• Shopify и Ruby Central взяли под контроль инфраструктуру RubyGems и Bundler, удалив ключевых мейнтейнеров, официально — для усиления безопасности supply chain.
• Сообщество раскололось: часть видит в действиях Shopify корпоративный захват, другие — необходимые меры после недавних атак на npm.
• Критики обвиняют Ruby Central в злоупотреблении властью и плохой коммуникации, особенно после передачи прав на репозитории без консенсуса.
• Наблюдатели отмечают, что конфликт усугубляется давними культурными разногласиями в сообществе Ruby, выходящими за рамки технических вопросов.

• Ruby Central предприняла резкие действия по ограничению доступа к инфраструктуре RubyGems из-за требований спонсора, угрожавшего отозвать финансирование из-за проблем с безопасностью цепочки поставок.
• Сообщество раскритиковало Ruby Central за катастрофически плохую коммуникацию, отсутствие предупреждения и прозрачности в процессе принятия решений, что привело к потере доверия.
• Действия были технически оправданы необходимостью безопасности, но метод исполнения (внезапный "переворот" без консультаций) признан неудачным и враждебным по отношению к добровольным maintainer'ам.
• Под вопросом остаётся независимость некоммерческой организации, которая оказалась под давлением крупных доноров, и её способность управлять критической инфраструкцией сообщества.
• Сообщество призывает к извинениям, восстановлению доверия через честный диалог и выработке более прозрачных процессов управления, чтобы избежать раскола в будущем.

Долголетний мейнтейнер RubyGems Эллен Даш описывает враждебный захват инфраструктуры со стороны Ruby Central. 9 сентября один из мейнтейнеров в одностороннем порядке переименовал GitHub-организацию «RubyGems» в «Ruby Central», добавил сотрудника Ruby Central Марти Хоута и удалил всех остальных мейнтейнеров. После критики изменения частично откатили, но 18 марта Хоут снова отозвал права доступа у всей команды RubyGems, Bundler и RubyGems.org, а Ruby Central заблокировал доступ к ключевым гемам.

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

• Ruby Central удалила давних мейнтейнеров RubyGems и Bundler без предупреждения и объяснений, что было воспринято как враждебный захват ключевой инфраструктуры.
• Сообщество выражает недоумение и требует прозрачных объяснений от Ruby Central, отмечая плохую коммуникацию и корпоративный тон их заявлений.
• Ruby Central опубликовала заявление о усилении безопасности и управления, ссылаясь на соответствие требованиям, но многие восприняли это как попытку оправдаться после факта.
• Некоторые участники предполагают, что за действиями Ruby Central стоят юристы и аудиторы, а не технические причины.
• Mike McQuaid и Homebrew выступают в роли медиаторов в попытке урегулировать конфликт между сторонами.

Делай вклад в цифровые общественные блага

Помоги проектам, которые борются с климатом, голодом и прочими глобальными задачами. Ниже — готовые к первому PR репозитории.

Проект	Язык	Направление
mautic	PHP	маркетинг-автоматизация
credebl	TypeScript	децентрализованная идентичность
avni-webapp	JavaScript	медицинские данные
the-turing-way	TeX	воспроизводимая наука
X-Road	Java	обмен данными между госорганами
OpenTermsArchive	JavaScript	прозрачность сервисов
OpenFn Lightning	Elixir	автоматизация workflow
android-fhir	Kotlin	мобильная медицина
casa	Ruby	волонтёрство для детей
ODK Collect	Kotlin	сбор данных в поле
cht-core	JavaScript	цифровое здравоохранение
policyengine-app	Jupyter	расчёт последствий политик
querido-diario	Python	открытые госгазеты
ODK Central	JavaScript	сервер для форм
decidim	Ruby	участие граждан

Фильтр по языку и Целям устойчивого развития (SDG) на сайте.

• Участники приветствуют инициативу списка проектов с «good first issue», но сомневаются в кураторстве: много проектов без активных задач, не все связаны с социальным влиянием.
• Предложено скрывать репозитории с 0 issues и добавлять метрики активности (коммиты, разработчики, возраст), как в Re-Decentralise.
• Новички спрашивают, считать ли правку опечаток «настоящим» вкладом; большинство советует упоминать, но честно указывать уровень участия.

Где живёт JIT-код

Ruby не выбрасывает байт-код — он остаётся в ISEQ. В структуре метода поле jit_entry либо NULL (интерпретатор), либо адрес скомпилированной машинной функции. Байт-код нужен для деоптимизации.

Как Ruby запускает JIT

Перед каждым вызовом метода VM проверяет jit_entry. Если указатель не нулевой — переход на него, иначе обычный интерпретатор. Одна проверка, один jmp.

Когда компилировать

ZJIT ждёт 25 вызовов для профилирования и 30 для компиляции (числа настраиваются). Пока счётчик jit_entry_calls не достигнет порога, метод работает в байт-коде.

Почему возвращаются к интерпретатору

JIT делает упрощающие предположения (типы, классы). Если они нарушаются — контроль возвращается к байт-коду, который всегда корректен. Это «деоптимизация»: быстро, но безопасно.

• Участники обсуждают, возможно ли ускорить Ruby с помощью фонового JIT, который постепенно перекомпилирует методы по мере накопления профильной информации (tiered compilation уже есть в .NET и JS-движках).
• Предложен снимок «прогретой» VM для мгновенного старта, но проблема — глобальное состояние C-библиотек; Emacs делает это через unexec.
• MRI Ruby не распараллеливает потоки и не дружит с JIT: язык позволяет динамически менять классы, что ломает оптимизации.
• Альтернатива — JRuby/TruffleRuby на JVM, но они теряют часть динамики и накладывают ограничения JVM.
• Соглашение: Ruby вряд ли догонит Java по скорости из-за динамической типизации и дизайна языка.

• Клод придумал три несуществующих метода Ruby; я бы тоже мог так «угадать», но не делаю этого, потому что помню, где и когда учил каждую деталь.
• Моя память «осадочная»: факты ощущаются плотными или пустыми, и я чувствую разницу между знанием и догадкой.
• У биологов до сих пор нет модели, что именно в мозге есть память; это центральная тайна человечества.
• У языковых моделей памяти нет: веса — как ДНК, а не как личный опыт. Контекстное окно — лишь блокнот в чужом номере.
• Чтобы перестать галлюцинировать, ИИ должен жить во времени и причинности, а не просто обрабатывать текст.

• Участники спорят, почему LLM «галлюцинируют»: кто-то винит сжатие знаний, кто-то — статистическую природу моделей.
• Нейробиологи и пациенты уточняют: человеческая память тоже ненадёжна, но у нас есть метапамять и эпизодические «якоря», которых у LLM нет.
• Документированная письменная база знаний считается лучшим способом снизить ошибки ИИ, пока не появятся принципиально новые архитектуры.
• Некоторые считают термин «галлюцинация» маркетинговым и предлагают называть это просто «ошибкой» или «склейкой».

RubyMine теперь бесплатен для некоммерческого использования

• Кому подходит: учёба, open-source, контент, хобби-проекты.
• Как получить: скачать RubyMine и выбрать «Non-commercial use».
• Коммерческое использование оплачивается по старой модели.

Почему?
JetBrains хочет снизить порог входа в Ruby и поддержать сообщество. Лицензия бесплатна, но включает анонимную телеметрию (только статистика функций).

• RubyMine считается «самым слабым» IDE от JetBrains из-за ограниченных возможностей самого Ruby.
• Тем не менее, у него лучший поиск, навигация и отладка по сравнению с ruby-lsp/VS Code, особенно при метапрограммировании.
• Бесплатная некоммерческая лицензия требует отправки анонимной статистики, что вызывает споры о «free as in freedom».
• AI-возможности уступают Cursor, но JetBrains-IDE всё равно предпочитают за стабильность и встроенный DataGrip.
• Некоторые видят в бесплатной лицензии попытку вернуть пользователей, ушедших к VS Code, и не считают это признаком «смерти Ruby».

• 0.9.11 – Ruby 3.2, libcurl 7.85+, исправлены утечки и сбои сборки.
• 0.9.10 – Ruby 2.7–3.1, Windows-CI, Curl.postal, Curl::Easy#resolve.
• 0.9.9 – Ruby 2.6+, Curl::Multi#max_connects, on_redirect, CURLOPT_UNIX_SOCKET_PATH.
• 0.9.8 – Ruby 2.5+, CURLOPT_SSL_VERIFYHOST, CURLOPT_SSL_VERIFYPEER, Curl::Easy#close.
• 0.9.7 – Ruby 2.4+, CURLOPT_TCP_KEEPALIVE, CURLOPT_TCP_KEEPIDLE, CURLOPT_TCP_KEEPINTVL.
• 0.9.6 – Ruby 2.3+, CURLOPT_SSL_ENABLE_ALPN, CURLOPT_SSL_ENABLE_NPN, Curl::Easy#on_header.
• 0.9.5 – Ruby 2.2+, CURLOPT_SSL_FALSESTART, CURLOPT_SSL_VERIFYSTATUS, Curl::Easy#on_progress.
• 0.9.4 – Ruby 2.1+, CURLOPT_SSL_SESSIONID_CACHE, CURLOPT_SSL_OPTIONS, Curl::Easy#on_debug.
• 0.9.3 – Ruby 2.0+, CURLOPT_SSL_CIPHER_LIST, CURLOPT_SSL_VERSION, Curl::Easy#on_body.
• 0.9.2 – Ruby 1.9+, CURLOPT_SSLCERT, CURLOPT_SSLKEY, Curl::Easy#on_header.
• 0.9.1 – Ruby 1.8+, CURLOPT_SSL_VERIFYPEER, CURLOPT_SSL_VERIFYHOST, Curl::Easy#on_complete.
• 0.9.0 – Первый релиз, поддержка Ruby 1.8, libcurl 7.10+.

• Вышла Curb 1.2.0: добавлен Fiber-aware IO-scheduling и параллельная сборка на нескольких ядрах, что ускоряет установку.
• По умолчанию Curl.head теперь не ждёт тело ответа (CURLOPT_NOBODY=1), что разумнее для HEAD-запросов.
• @sdwolfz поздравил и спросил, в чём преимущество Curb перед Net::HTTP для обычных JSON REST-вызовов, кроме «меньше кода».

rv — новый Ruby-менеджер
Десять лет я мечтал о менеджере, который одновременно управляет Ruby-версиями, ставит уже скомпилированные интерпретаторы и запускает любой скрипт без конфликтов. Такой инструмент уже есть — это Python-утилита uv. Вдохновившись ею, я начал делать rv.

Что умеет rv

• Написан на Rust ⇒ всё мгновенно: установка Ruby 3.4.x на macOS/Ubuntu занимает 1 с.
• rv tool run — запуск любой gem-команды (gist, rubocop, …) в изолированном окружении без предварительной настройки.
• rv tool install — ставит CLI-утилиту с собственным Ruby и гемами, не трогая проект.
• Однофайловые скрипты: внутри .rb хранятся версия Ruby и lock-файл; rv run script.rb — и всё работает.
• Единая команда вместо цепочки rvm install, bundle install, bundle exec.

Команда и статус
Уже подключились Samuel Giddins (RubyGems) и Sam Stephenson (rbenv). Сейчас rv умеет переключать Ruby в zsh и ставить готовые сборки.
Попробовать: spinel-coop/rv и roadmap.

• Участники обсуждают новый инструмент rv для Ruby, вдохновлённый uv из Python-мира.
• Одни рады скорости и «одному инструменту для всего» (Ruby + gems + инструменты), другие считают, что Bundler и так работает нормально.
• Часть разработчиков предпочитает универсальные менеджеры (mise, asdf, Nix), чтобы не плодить отдельные утилиты под каждый язык.
• Есть опасения, что Ruby может пойти по пути «venv-ада» Python или потребовать Rust для вклада.
• Несколько человек просят сравнительную таблицу с rvm/rbenv и поддержку .tool-versions.

Перешёл в компанию, где стек — Python. Выбор был не из-за языка: Python мне всегда казался гигантским красным флагом. Тем не менее, начинаю к нему привыкать.

Почему я любил Ruby

Ruby — мой первый «язык-любовь»: всё объект, if можно переписать блоками, method_missing позволяет метапрограммировать. Он черпал у Smalltalk и Lisp, и это вдохновляло.

Почему ненавидел Python

Python казался «хуже Ruby» и «ещё хуже Scheme». if — оператор, а не выражение; lambda уродливые; до Python 3 print вообще был оператором. Один «правильный» способ делать всё раздражал.

Типы для нетипизированного

Потом пришёл TypeScript: мощная система типов, narrowing, conditional types. Плохие конструкции языка прощаются статическим анализом.

Я изменился

TypeScript научил: отсутствие match или if-выражения пережить, если компилятор проверит инициализацию. Rust показал, что мутабельность — не зло.

Python изменился

Теперь в Python есть type hints, match с деструктуризацией, а print — функция.

• Автор рассказал, как после появления VSCode и LSP перестал использовать языки без типов и теперь не хочет возвращаться к Ruby без нормальной типизации.
• Участники обсуждают, что Ruby остаётся элегантным и «радостным», но его отказ от постепенной типизации (включая Sorbet) отталкивает многих.
• Python, напротив, эволюционирует: появились аннотации типов, LSP, но язык стал сложнее и уже не «выучить за выходные».
• Некоторые считают, что страсть к Ruby — это ностальгия, а промышленность требует стабильности и инструментов, которые дают статические языки.
• Общий вывод: выбор языка всё чаще диктуется экосистемой, инструментами и личными приоритетами, а не чистой «красотой» синтаксиса.

Как 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 оставаться стабильным и «не-эншиттифицированным».

Top Secret — новая open-source библиотека от thoughtbot для удаления чувствительных данных из произвольного текста.

Проблема: регулярки не ловят всё (имена, адреса, карты). Решение: смесь regex и NER (распознавание именованных сущностей) через гем mitie-ruby.

Как работает:

1. TopSecret::Text.filter заменяет сущности на токены [PERSON_1], [LOCATION_1] и возвращает mapping.
2. После ответа LLM вызываем TopSecret::FilteredText.restore, чтобы вернуть реальные значения.

Пример:

input  = "Ralph lives in Boston."
filtered = TopSecret::Text.filter(input)
#=> "[PERSON_1] lives in [LOCATION_1]."
mapping  = { PERSON_1: "Ralph", LOCATION_1: "Boston" }

response = "Hi [PERSON_1]! How is the weather in [LOCATION_1]?"
TopSecret::FilteredText.restore(response, mapping: mapping)
#=> "Hi Ralph! How is the weather in Boston?"

Подходит для чат-ботов, где нужно скрыть персональные данные, но сохранить контекст.
Код и демо: GitHub и стрим.

• Обсуждают лёгкий NER-фильтр на базе MITIE для автоматического скрытия чувствительных данных в строках.
• US Marshalls уже заинтересовались такой «авто-редактурой».
• Участники предупреждают: NER не 100 % точен, модель старая (~10 лет) и плохо переносится на новые домены.
• Возникает вопрос, можно ли применять фильтр к стримингу/шерингу экрана: технически возможно через accessibility-API, но нужно определять координаты сущностей и бороться с ложными срабатываниями.
• Для продакшена с длинными диалогами 1 с на инференс может быть медленно; логировать через LLM-фильтр тоже рискует «убить» скорость.

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.

Как я ускорил Ruby до скорости Ruby

P2 — новая библиотека шаблонов, где HTML описывается чистым Ruby. В отличие от ERB, исходный код шаблона не исполняется: он компилируется в эффективный Ruby-код, который генерирует HTML. Это делает P2 первой библиотекой, использующей компиляцию исключительно.

Как работает компиляция

Шаблон — это Proc:

->(title:) {
  html { body { h1 title } }
}.render(title: 'Hi')

При вызове #render код превращается в:

->(buf, title) {
  buf << "<html><body><h1>"
  buf << ERB::Escape.html_escape(title.to_s)
  buf << "</h1></body></html>"
  buf
}

1. Парсинг: Sirop читает файл и строит AST через Prism.
2. Трансформация: TagTranslator заменяет CallNode на TagNode, если вызов соответствует HTML-тегу без получателя.
3. Обратный код: подкласс Sourcifier преобразует AST обратно в Ruby, подставляя строки буфера и экранирование.

Оптимизация

Jean Boussier указал узкие места и направления. В результате генерация стала заметно быстрее «чистого» Ruby.

• Автор создал альтернативу ERB, ускорил её до сопоставимой скорости, но, по мнению @swombat, выводит ошибочное заключение.
• @ciconia (автор) спорит: производительность Ruby важна, его системы выдают >1K RPS.
• @barrkel: Ruby медленнее, но быстрее Python; у каждого свои пути к скорости.
• @Alifatisk: сравнивать Ruby с Rust бессмысленно — языки для разных задач.
• Остальные комментарии свелись к старому мему «yo dawg».

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.

This is one of the features that Ruby cribbed directly from Perl. The Ruby documentation seems really bad, in particular “interpolation mode” is grievously misleading.Perl’s documentation is far more clear about the consequences:(https://perldoc.perl.org/perlop#Regexp-Quote-Like-