Ruby

Возврат к истокам

Evrone digest — Mon, 18 Sep 2023 10:26:02 +0000

Принимать непопулярные решения сложно. Но это не помешало Дэвиду Хейнемейеру Ханссону заявить, что он с удовольствием откажется от TypeScript в будущем релизе Turbo 8. Вместе с причинами этого поступка мы расскажем о втором превью Ruby 3.3.0 и узнаем о том, что такое I.D.E.A.L. по версии Злых Марсиан.

DHH: TypeScript мне только мешает

Два года назад, в первый день Ruby Russia’21, DHH громко заявил о новом стеке технологий Hotwire (Turbo 7 + Stimulus 3). Об этом мы писали в одном из наших дайджестов. Забавно совпало — снова громкое заявление накануне Ruby Russia’23. Теперь DHH заявил, что в следующем мажорном обновлении Turbo 8 будет убрана поддержка TypeScript. Это вызвало бурные обсуждения в сообществе, так что мы решили узнать причину такого решения.

Холивар вокруг статической и динамической типизации продолжается уже много лет. Идея наполнить JS явными типами и иметь возможность проверять их компилятором нравится многим программистам, но не DHH. Для него необходимость использования компилятора и «загрязнение кода» указанием типов никак не добавило радости процессу разработки, скорее наоборот. Лёгкие вещи стали сложнее, а трудные превратились в мучение. Так что решение выпилить TS из Turbo 8 стало очевидным способом облегчить себе жизнь и одновременно сделать код чище.

Важно понимать, что у разработчиков никто не отбирает возможность писать на TS или включать библиотеки, которые используют TS. Но, по мнению DHH, в конечном итоге запуск кода в браузере будет означать запуск JS. А значит наиболее правильным будет использовать те «плюшки», которые даёт динамическая типизация. Своего рода возвращение к истоками, ведь JS изначально был свободен от статической типизации. Возвращение к этой свободе будет для Turbo 8 лучшим выбором (по мнению Дэвида).

Митапы

Онлайн

Ruby Russia

30 сентября 2023

Один день, 14 новейших докладов, запись в высоком разрешении — всё это RubyRussia’23. Мы соберём рубистов со всей России и ближнего зарубежья, чтобы с ведущими разработчиками обсудить будущее нашего любимого языка и всего, что построено вокруг него.

Онлайн-конференция — одновременно шоу для коллег-разработчиков и площадка для обсуждений. Присоединяйтесь к нашей трансляции: вас ждут ёмкие 20-минутные доклады, общение с коллегами по стеку и развлечения от наших партнёров.

Регистрация

Второе превью Ruby 3.3.0

Мы уже упоминали выход первого превью Ruby 3.3.0 и дебют RJIT. Из подробностей можно отметить, что пока будет поддерживаться только архитектура x86-64 на Unix. Разумеется, пока что RJIT лишь экспериментальная функция и годится лишь для тестовых целей.

Ещё одно интересное предложение поступило относительно парсинг-генератора. В данный момент Ruby полагается на Bison, и это вызывало некоторые проблемы с совместимостью. Kaneko Yuichiro предложил заменить Bison на Lrama LALR. Этот парсинг-генератор создан на чистом Ruby и более устойчив к ошибкам. Matz согласился с предложением и отметил, что это поможет решить проблемы совместимости в будущих версиях.

Большая часть изменений коснётся YJIT. Помимо улучшенной поддержки аргументов splat и rest, было внесено множество доработок для увеличения производительности. Удалось даже разогнать знаменитый эмулятор optcarrot более чем в 3 раза. Метаданные для скомпилированного кода теперь занимают меньше памяти, а приложения для архитектуры ARM64 получаются компактнее. Помимо этого появилась интересная фича, позволяющая поставить YJIT на паузу. Это можно использовать, чтобы включать YJIT в работу только после запуска приложения.

I.D.E.A.L. от Злых Марсиан

Наши инопланетные «коллеги по цеху» на днях выпустили отличный сборник best practices по использованию HTTP-клиентов. Шутливое название I.D.E.A.L. поневоле ассоциируется с боевой системой V.A.T.S. (Vault-Tec Assisted Targeting System) из Fallout 3. Здесь же аббревиатура представляет собой набор принципов:

I — Investing in stability (mandatory)
D — Debugging uncertainties (mandatory)
E — Exploring the client (mandatory)
A — Advancing with abstractions (opinionated)
L — Laying out a sound structure (opinionated)

HTTP-соединения по своей природе нестабильны: пакеты теряются, а сервисы могут вести себя непредсказуемо. Для достижения первого принципа инвестирования в стабильность потребуется чётко определить рамки, при выходе за которые пора поднимать тревогу. Грамотно настроенные таймауты соединения не позволят вашим сервисам зависать на неопределённое время. К этому же принципу стоит отнести настройку повторных попыток подключения.

В мире нет ни одного программиста, которому не приходилось сталкиваться с отладкой неопределённого поведения приложения. Здесь для соблюдения принципа Debugging uncertainties имеет смысл вести журнал внешних запросов. Поначалу он может показаться дополнительной бесполезной рутиной, но это впечатление обманчиво. Когда вы столкнётесь с неопределенным поведением, этот журнал станет вашим козырем в рукаве. Вести такой журнал можно как собственными силами, так и с помощью готового решения, например, Yabeda.

Почитать про остальные принципы можно в оригинальной статье Evil Martians.

Вакансии

Удаленка / Офис

Evrone

Мы открыты для новых Ruby-разработчиков. В Evrone можно работать удалённо с первого дня, мы поддерживаем и оплачиваем участие в Open-source проектах и выступления на конференциях, а расти в грейдах можно с помощью честной системы проверки навыков и менторства.

Подробнее

Код, который пишет код

Evrone digest — Thu, 03 Aug 2023 10:28:36 +0000

Время летит незаметно и пришла пора выпустить наш августовский Ruby-дайджест. В нём поговорим про метапрограммирование и устроим небольшую Q&A-сессию на тему сборки мусора. Бонусом расскажем, как использовать платформу Jupiter notebook не с Python, а с Ruby.

Метапрограммирование в Ruby

Многие разработчики мечтают освоить метапрограммирование, но придерживаются принципа из фильма «О чём говорят мужчины»:

«— А так, а так она мечта, её не нужно трогать руками.

— Слав, не трогай руками!»

Перед тем, как тратить своё драгоценное время, стоит задуматься: «А что даст это знание?». Если кратко, то метапрограммирование поможет:

cоблюдать принцип DRY (Don't repeat yourself);
эффективно переиспользовать собственный код;
легче решать проблемы со сторонними зависимостями, в которых используется метапрограммирование.

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

В начале даже нет нужды сразу погружаться во все тонкости. Хорошей идеей будет освоить хотя бы три простых метода: send, define_method и method_missing:

Send обеспечивает динамическую передачу методов объектам. При этом необязательно знать, каким будет объект или метод во время написания кода. Вызов делается следующим образом: my_object.send(:method_name). А для передачи дополнительных аргументов используется: my_object.send(:method_name, argument1, argument2...). Send может принимать именованные аргументы или методы. Это даёт возможность сильно упростить код. Например:

def sell_or_refund_or_return_item(item, action) if action == "sell" item.sell elsif action == "refund" item.refund elsif action == "void" item.void elsif action == "return" item.return end end

Его можно легко переписать, передав метод в качестве аргумента. Вызываем его через send. Profit:

def process_item(item, action) return unless item.respond_to?(action) item.send(action) end

Будьте осторожны, поскольку send может вызывать как общедоступные, так и приватные методы. Если надо убедиться, что вызван именно общедоступный метод, лучше воспользоваться public_send.

Если не испугались этого примера и хотите узнать больше об остальных методах, то рекомендуем почитать профильную статью в блоге AppSignal.

Q&A по GC

В одном из наших прошлых дайджестов мы рассказывали, как уберечь приложение от рук OOM-киллера и предотвратить утечки памяти. Сегодня попробуем взглянуть на этот механизм чуть пристальнее в формате Q&A.

Где в Ruby живёт сборщик мусора? В файле gc.c. Помимо сборки мусора, код из этого файла отвечает за выделение и управление памятью. Сборщик мусора полностью контролирует весь жизненный цикл созданных объектов, за редким исключением.

Все ли типы объектов работают одинаково? Формально можно разделить все типы на 2 группы. Первая — immediates. Объекты этой группы типов ведут себя как остальные, но при этом не подчиняются сборщику мусора. Например, nil, true/false, Fixnum (в диапазоне между -(2**62) и 2**62 - 1 на 64-битных системах), числа с плавающей точкой (за исключением некоторых) и статические символы. Вторая группа объектов, heap allocated, целиком полагается на управление сборщиком мусора.

Сколько бывает типов объектов в куче? В общей сложности существует 14 типов объектов.

Какой тип у указателей на объекты Ruby? Тип VALUE.

Из чего состоит куча? Куча состоит из страниц, каждая из которых имеет размер 64 КБ. Далее страницы делятся на слоты фиксированного размера. У каждой страницы слоты имеют единый размер в 40 байт. Если несколько объектов будут повторяться на одной странице памяти, то не потребуется не изменять размеры слотов.

Как выделяется память? Сборщик памяти выделяет память постранично, а не отдельными слотами. Это обусловлено соображениями производительности. Выделять память реже, но большими порциями эффективнее, чем часто, но маленькими.

Как работает Variable Width Allocation? Смысл этой функции в предоставлении разработчикам API для выделения объектов динамического размера. Также она добавляет поддержку слотов переменного размера внутри сборщика мусора. Жаль лишь, что функция не поддерживает все типы объектов.

Что такое fast path? Термин fast path применим к распределению памяти для абстракций Ractor. Каждый экземпляр класса Ractor имеет кэш, который заранее содержит список связанных свободных слотов. Забронировав свободные слоты, несколько экземпляров Ractor могут выделять память объектам параллельно, без риска возникновения условий гонки. Это работает, пока свободные слоты в кэше не кончатся. Тогда придётся использовать slow path.

Что такое slow path? Каждый Ractor поочерёдно блокирует виртуальную машину Ruby и начинает искать связанные списки свободных слотов по страницам кучи. Как только такая страница найдена, список перемещается в кэш Ractor. Если поиск успехом не увенчался, то система проверяет разрешение на выделение новой страницы кучи и если оно есть, то происходит выделение новой страницы. Отсутствие разрешение означает, что запущен цикл сборки мусора и надо подождать его окончания.

Правда ли, что код Ruby перестаёт выполняться, когда выполняется цикл сборки мусора? Так и есть. Как в знаменитой рекламе «…и пусть весь мир подождёт». В больших приложениях это может вызывать длительные паузы. Чтобы избежать этого, в Ruby применяется два решения: инкрементная маркировка объектов и использование сборщика мусора на основе поколений.

Надеемся, что такая маленькая Q&A-сессия освежила ваши знания. Ну а если хотите узнать ещё подробностей про сборку мусора в Ruby, то советуем заглянуть в статью Garbage Collection in Ruby.

Jupiter notebooks для Ruby

Что приходит на ум, когда вы слышите словосочетание «Jupiter notebook»? Правильно — Python. Исторически так сложилось, что чаще всего функциональность платформы Jupiter notebook требуется специалистам по анализу данных. Те, в свою очередь, задействуют обширный инструментарий, вроде NumPy, pandas и Matplotlib. Все они написаны на Python, так что именно с ним чаще всего приходится иметь дело.

На самом деле, Jupiter notebook отлично сочетается с Ruby. Есть крутой проект IRuby, представляющий собой Ruby-ядро для проекта Jupiter. Вначале установим Jupiter с помощью инсталлятора Python:

pip install jupyter

IRuby поставляется в виде обычного gem. Устанавливаем:

gem install iruby

Регистрируем IRuby в качестве ядра для Jupiter:

iruby register --force

Открываем Jupiter Notebook:

jupyter notebook

Далее Kernel > Change kernel. Там будет доступен Ruby. Осталось создать свой первый Ruby notebook и создать Hello World для проверки:

puts "Hello, world!"

Писать всё в одиночку скучно. Предлагаем привлечь к этому делу генеративную нейросеть от OpenAI. Для этого предусмотрен соответствующий gem. Его можно установить отдельно или указать в качестве зависимости. Можно написать прямо в notebook:

require "bundler/inline" gemfile do source "https://rubygems.org" gem "dotenv", require: "dotenv/load" gem "ruby-openai" end

Здесь помимо ruby-openai указан dotenv. Это нужно для удобного хранения токена OpenAI в файле с расширением .env. Его можно будет положить прямо в директорию c notebook. Содержимое файла будет выглядеть так:

OPENAI_ACCESS_TOKEN=your_key

Теперь можно инициализировать клиент строкой:

client = OpenAI::Client.new(access_token: ENV["OPENAI_ACCESS_TOKEN"])

Для проверки возьмём пример из README проекта ruby-openai:

response = client.chat( parameters: { model: "gpt-3.5-turbo", messages: [{ role: "user", content: "Hello!"}], temperature: 0.7, } )

Если у вас есть действующая подписка и валидный токен, то система в ответ на приветствие выдаст что-то вроде «Hello! How can I assist you today?». Удачных экспериментов!

Митапы

Онлайн

Ruby meetup

22 ноября 2023

Осенью у нас состоится ещё один Ruby Meetup, который пройдёт в формате онлайн. Программа мероприятия формируется и скоро станет доступна на странице мероприятия. Кстати, если вы не успели подать доклад, то можете это сделать прямо в режиме онлайн. Заявки на участие принимаются до 1 ноября.

Теперь следить за митапами Evrone стало удобнее. В Telegram-канале Evrone meetups мы выкладываем анонсы с подробными описаниями докладов, а также студийные записи после мероприятий. А ещё, у нас можно выступить, мы поможем оформить вашу экспертизу в яркое выступление. Подписывайтесь и пишите @andrew_aquariuss, чтобы узнать подробности.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Ещё парочку

Evrone digest — Mon, 10 Jul 2023 14:08:45 +0000

Этот дайджест мы посвятили двум крутым фреймворкам: Glimmer и Camping. Первый позволяет создавать крутые GUI-приложения на Ruby, а второй — делать веб-приложения. Бонусом обсудили, являются ли векторы «новым JSON».

Строим GUI через Glimmer

Если нужно создать нативное приложение с графическом интерфейсом на Ruby, советуем обратить внимание на DSL-фреймворк Glimmer. Название произошло от сокращённого выражения «Glimmer of Ruby in Graphical User Interfaces», то есть «проблеск Ruby в графических пользовательских интерфейсах». Аббревиатура DSL (Domain-specific language) в названии указывает на использование синтаксиса, «заточенного» под описание графических интерфейсов. Получается такой мини-язык внутри языка.

Автор Glimmer, канадский программист Энди Малех (Andy Maleh) изначально задумывал Glimmer, как простую библиотеку, добавляющую графический интерфейс. Позже она превратилась в полноценный фреймворк. Идея родилась в 2007 году, когда Энди со своим коллегой занимались парным программированием. Им обоим пришло в голову, что синтаксис связывания данных неплохо было бы упростить.

На тот момент они частенько писали что-то вроде:

dbc.bind(nameTextBox, new Property(person, "name"), null); dbc.bind(ageSpinner, new Property(person, "age"), null);

В качестве идеи родился абстрактный вариант:

(nameTextBox, text) <=> (person, name) (ageSpinner, selection) <=> (person, age)

Который в Ruby выглядел вообще шикарно:

[@name_text_box, :text] <=> [@person, :name] [@age_spinner, :selection] <=> [@person, :age]

Оператор <=>, остроумно прозванный космическим кораблём, в DSL Glimmer означает двустороннее связывание данных. Одностороннее связывание обозначалось бы оператором <=. С лёгкой руки этот синтаксис назвали Shine.

Собственно, Glimmer состоит из двух частей: DSL-движка и библиотеки связывания данных. Его синтаксис ограничен mixin-классами, что позволяет не засорять пространство имён. Разработчик всё также пишет на обычном Ruby, но когда надо, использует синтаксис Glimmer. Вот, как выглядит Hello, world с использованием DSL Glimmer для LibUI:

require 'glimmer-dsl-libui' include Glimmer window('hello world').show

Стоит ли повнимательнее изучить возможности Glimmer? На мероприятии Fukuoka Ruby Awards в 2022 Glimmer заслужил специальную награду и пожелание успеха от самого Матца. Отличный повод попробовать и сделать собственные выводы.

Микрофреймворк Camping

Давно ли вы ходили в поход? Главное правило сбора рюкзака — соблюсти баланс между пользой и весом. Каждая вещь может расширить ваши возможности, но увеличит вес. Если переборщить с весом, то до применения дело может вовсе не дойти. А если взять слишком мало, то нехватка возможностей также не даст шанс завершить поход успешно.

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

Camping изначально был создан легендарным Джонатаном Джиллеттом (Jonathan Gillette), более известным под псевдонимом why the lucky stiff. Наряду с Matz и DHH, он одна из ключевых фигур сообщества Ruby, хоть и полностью исчезнувший из инфополя 11 лет назад (об этом можно узнать в статье Where’s _why?). Развитие Camping было продолжено сообществом разработчиков.

Идея Camping в том, чтобы всё веб-приложение умещалось в один файл и при этом было построено по модели MVC (Model-View-Controller). Да и сам микрофреймворк получился крошечным, менее 5 килобайт. Чтобы «выезд на природу» был проще, у Camping есть структурированная документация: The Camping Book. В ней есть и общая информация, и простые примеры.

Отдельно отметим, что запущенный camping-сервер не требуется перезапускать при изменениях файлов. Вы просто их редактируете, а camping автоматически выполнит перезапуск. Если у вас есть несколько веб-приложений на этом фреймворке со своими индивидуальными моделями, контроллерами и маршрутизацией, то из них можно сделать единое целое. Camping умеет обслуживать такой объединённый код и это делает его ещё интереснее.

Векторы — новый JSON

Именно так утверждает программист из Нью-Йорка, Джонатан Кац (Jonathan S. Katz). Мнение достаточно странное, ведь векторы — это математическая структура, а JSON — формат обмена данными. Но бурное развитие генеративных нейронных сетей уже создаёт запрос на удобные способы хранения и выполнения запросов к ним. И удовлетворить такой запрос могут векторы, которые давным-давно используют массивы в качестве базовой структуры данных. Ну а для хранения векторов вполне можно использовать PostgreSQL.

Всё это очень напоминает 2012 год. У многих тогда была необходимость где-то хранить данные в JSON. Релиз PostgreSQL 9.2, в котором впервые был добавлен текстовый тип JSON, стал очень ожидаемым событием. Изначальная поддержка была весьма скромной: встроенной индексации не было, система могла выполнять лишь простые действия по извлечению данных и гарантировала пользователю, что в базе находится только валидный JSON.

Эксперимент получился успешным и уже в PostgreSQL 9.4 появился формат JSONB, представляющий бинарный, а не текстовый тип JSON. Это дало возможность создавать индексы GIN (Generalized Inverted Index) и поставило производительность PostgreSQL в один ряд со специализированными базами данных. Приятным бонусом становятся все преимущества хранения в реляционной БД.

Современные AI и ML-системы на выходе дают векторы, которые можно хранить в PostgreSQL. Но есть целый ряд ограничений, которые мешают это делать. В частности, такой тип данных, как cube, позволяет хранить векторы максимум с 100 измерениями. По нынешним меркам этого мало. Расширение pgvector добавляет новый тип данных vector и метод индексации IVF FLAT. Этого уже вполне достаточно, чтобы хранить векторные данные в PostgreSQL и выполнять семантический поиск по ним.

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

Интересно посмотреть

Пропустили наш предыдущий митап? Не страшно! Видеозаписи докладов уже выложены на нашем YouTube-канале в кинематографическом качестве 4K и со студийным звуком.

Подписывайтесь и ставьте 🔔колокольчик, чтобы получать уведомления о будущих трансляциях и видео! А ещё присоединяйтесь к Telegram-каналу и будьте в курсе всех наших будущих мероприятий.

Митапы

Онлайн

Ruby meetup

30 августа 2023

В конце лета мы запланировали ещё один Ruby Meetup, который пройдёт в формате онлайн. Программа мероприятия формируется и скоро станет доступна на странице мероприятия. Кстати, если вы не успели подать доклад, то можете это сделать прямо в режиме онлайн. Заявки на участие принимаются до 10 августа.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Монолит вместо микросервисов

Evrone digest — Thu, 01 Jun 2023 11:38:23 +0000

Идти против тренда непросто, но это иногда приносит хороший результат. Расскажем, почему в одном из сервисов Amazon полностью отказалась от микросервисной архитектуры в пользу монолита. Ещё обсудим обновления полезных библиотек и экспериментальный JIT-компилятор, включённый в первое превью Ruby 3.3.0.

Amazon отказывается от микросервисов?

В то время, как разные компании разбивают монолиты на микросервисы, некоторые делают полностью противоположные вещи. Если против тренда идёт никому не известная компания, то можно покрутить пальцем у виска и не брать это в расчёт. Но когда мы говорим об опыте Amazon, игнорировать его будет странно. Мы обратили внимание на этот кейс после публикации в блоге автора Ruby on Rails, Дэвида Хейнемейера Ханссона. Кстати, мы брали у него интервью, которое можно найти на нашем сайте.

Команда сервиса Amazon Prime Video решила полностью отказаться от микросервисной архитектуры, заменив её монолитом. И результат оказался ошеломляющим — удалось сэкономить почти 90% эксплуатационных расходов, а система стала проще. Звучит удивительно, поскольку их инфраструктура изначально проектировалась как serverless-решение с прицелом на независимое масштабирование каждого компонента. Но в процессе использования был достигнут жёсткий предел масштабирования, а стоимость компонентов была бы непомерно высока.

Сам сервис, который они строили, состоял из трёх основных компонентов: медиаконвертера, анализаторов дефектов и оркестратора потоков для управления всем этим безобразием. Первая ошибка: отдать управление оркестровкой компоненту AWS Step Function. Последнему для эффективной работы требовалось каждую секунду потока выполнять по несколько переходов состояния. Так что вскоре они упёрлись в лимит аккаунта, а также высокую стоимость, так как за каждый такой переход взимается плата.

Вторая проблема была ещё интереснее. Каждый анализатор дефектов был реализован, как микросервис, использующий AWS Lambda для обработки кадров. Эти кадры, в свою очередь, готовились другим микросервисом, который разбивал видео и временно загружал полученные изображения в объектное хранилище AWS S3. Всё это отлично работало, но общее количество вызовов в соответствующий S3 bucket было огромным и стоило слишком дорого.

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

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

По словам DHH, во многих отношениях микросервисы — это зомби-архитектура, которая уже стала токсичной. Замена вызовов методов на сетевые вызовы с разделением сервисов в рамках единой согласованной команды почти всегда становится безумной затеей. Вовсе не факт, что микросервисы решат задачу клиента, а вот навредить могут.

Nokogiri 1.15 вышла в релиз

Если вы часто работаете с XML и HTML в Ruby, то наверняка пробовали Nokogiri. Эта библиотека предоставляет простой и понятный API, имея внутри себя нативные парсеры, такие как libxml2, libgumbo и xerces. Она спроектирована быть безопасной по-умолчанию, а также создаёт удобную для разработки абстракцию, которая не пытается исправить поведенческие различия между парсерами. Удобства ради поставляется в виде предварительно скомпилированных гемов для различных платформ. Установка чаще всего выполняется одной командой:

gem install nokogiri

Если вы уже пользовались Nokogiri ранее, то вышедшее обновление должно вас приятно удивить. С момента выхода первой версии, парсер libxml2 использовал ruby_xmalloc для управления памятью. Это было хорошим решением на тот момент, поскольку давало гибкость. Платой за это была производительность. С версии 1.15 у разработчика появляется возможность выбирать. Теперь можно пожертвовать гибкостью в обмен на производительность, выбрав системный malloc вместо ruby_xmalloc. Делается это через переменную окружения:

# "default" here means "libxml2's default" which is system malloc NOKOGIRI_LIBXML_MEMORY_MANAGEMENT=default

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

Помимо этого нововведения была исправлены ошибки в поведении libxml2 и libxslt, вызывающие segfault. Если в документе присутствуют пустые текстовые узлы с созданными для них объектами Ruby, то будет создаваться защитная копия документа. Небольшая потеря скорости, в данном случае, лучше небезопасного доступа к памяти и потенциальному segfault.

Будущий RJIT

12 мая был открыт доступ к первой превью-версии будущего релиза Ruby. Помимо штатного и официально рекомендуемого компилятора YJIT, в сборку добавлен экспериментальный компилятор RJIT. Существующие компиляторы MJIT и YJIT имеют общий недостаток — они оба полагаются на внешние компиляторы. MJIT зависит от компилятора языка C во время выполнения, а YJIT от компилятора Rust во время сборки. Ноу-хау RJIT в том, что он создан на чистом Ruby, что делает его полностью самодостаточным.

Звучит отлично, но пока что RJIT не самый оптимальный вариант, даже с учётом того, что он генерирует код, аналогичный YJIT. Последний значительно быстрее и стабильнее, особенно после оптимизации в будущей версии 3.3.0.

По словам Такаши Кокубуна (Takashi Kokubun), штатного Ruby-разработчика в Shopify, есть два ключевых фактора, которые для RJIT пока недостижимы. Первый — время прогрева. Для JIT-компиляторов характерно следующее поведение: первое выполнение какой-либо функции будет медленнее, чем последующие вызовы этой же функции. Соответственно, программа со временем начинает работать значительно быстрее. Чем меньше время прогрева, тем лучше.

Второй фактор — объём потребляемой памяти. Если Ruby-приложение развёртывается на небольшой инфраструктуре, то этот фактор не играет большой роли. Но когда речь идёт о крупномасштабных кластерах, то каждый лишний мегабайт начинает существенно влиять на стоимость эксплуатации. Достигнуть компромисса для RJIT будет сложнейшей задачей, так что не стоит пока списывать со счетов YJIT. Но сам факт того, что альтернативные варианты включаются в язык, заставляют задуматься, что в этом направлении есть потенциал для совершенствования.

Ну и напоследок, раз уже начали говорить о грядущем обновлении Ruby, отметим, что нас ждут изменения некоторых гемов в стандартной библиотеке. В частности, будут затронуты RubyGems, bigdecimal, bundler и syntax_suggest.

Экосистема TTY

Пару дней назад обновился парсер tty-option из TTY Toolkit, это побудило нас написать об этом старом, но надёжном наборе инструментов. В нём 24 плагина для взаимодействия с командной строкой. Каждый из них максимально прост и годится для выполнения конкретной задачи. Но при необходимости их легко комбинировать между собой и получать достойный результат. Всё это очень напоминает бар, где каждый напиток хорош сам по себе, но смешайте их и получится что-то новое.

Чтобы получить доступ сразу ко всем инструментам из набора введите следующую команду в терминале:

gem install ‘tty’

Теперь вам станут доступны многие джедайские техники. Например, tty:cursor позволяет перемещать курсор терминала в нужные вам координаты. Также есть простые методы, вроде перемещения курсора на строку вверх или вниз. Ещё есть прекрасная функция очистки экрана целиком, текущей строки или заданного количества строк.

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

require 'tty-cursor' require 'tty-screen' @cursor = TTY::Cursor @size = TTY::Screen.size # => [height, width] @height = @size[0] @width = @size[1] def move_cursor_to_required_coordinates(text) x = (@size[1] - text.length) / 2 y = (@size[0]) / 2 print @cursor.move_to(x, y) end def centered_text(text) move_cursor_to_required_coordinates(text) puts text end centered_text("welcome to the center")

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

Митапы

Онлайн

Ruby meetup

05 июля 2023

Летом мы встретимся с вами на замечательном Ruby Meetup, который пройдёт в Москве. Программа мероприятия формируется и скоро станет доступна на странице мероприятия. Кстати, если вы не успели подать доклад, то можете это сделать прямо в режиме онлайн. Заявки на участие принимаются до 20 июня.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Сложнее, чем кажется

Evrone digest — Tue, 02 May 2023 11:16:21 +0000

В майском выпуске мы разберёмся, почему тесты в CI глючат чаще, чем при локальных прогонах. Также расскажем о подводных камнях при парсинге CSV-файлов и предупреждениях об устаревании.

Почему тесты в CI глючат чаще

Один и тот же тест может проходить успешно или заканчиваться падением, даже если код не менялся. Такое случается, если в коде приложения или теста проявляется своеобразный недетерминизм. В таком коде 2 + 2 не всегда будет равно 4. Иногда это 3, а иногда 5. При запуске на тестовый прогон CI, ситуации с нестабильностью возникают значительно чаще, чем при локальном прогоне.

Такое случается по причинам:

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

Посмотрим на них с точки зрения выполнения тестов. Если один тест пропускает в глобальную среду какое-то состояние (поменявшийся файл или переменную окружения), то это влияет на последующие тесты. В CI это случается чаще, поскольку тесты запускаются «пачками», а не по одному, как при локальном прогоне. Это даёт тестам больше возможностей мешать друг другу, даже когда CI старается изолировать запуски.

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

Это лишь пара примеров, объясняющих проблемы в процессе тестирования. Чтобы узнать больше деталей, советуем прочитать статью Why tests flake more on CI than locally, написанную американским программистом Джейсоном Светтом (Jason Swett).

Обманчиво простой парсинг CSV

CSV-формату «стукнуло» уже более полувека, но он всё ещё супер-популярный. Его используют для того, чтобы хранить таблицы в текстовом виде. Название CSV расшифровывается, как Comma-Separated Values, дословно «значения, разделённые запятыми». Но это уже немного лукавство, ведь CSV не полностью стандартизирован, так что значения легко могут разделяться точками с запятой или вообще табуляцией.

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

Взглянем на симптомы, часто возникающие у приложения в процессе парсинга.

Например, высокое использование памяти. Методы read и parse хорошо работают лишь до того момента, пока вам не попадётся действительно большой CSV-файл. Проблема в том, что оба этих метода полностью загружают все данные в память. Чтобы этого избежать, мы рекомендуем использовать метод foreach.

Ещё часто встречаются дублированные заголовки, такие как:

first_name,last_name,email,first_name,age\n John,Doe,doe@gmail.com,Johnatan,30\n Tom,Doe,tom@gmail.com,Thomas,40\n

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

data = CSV.read("./duplications.csv", headers: true) transformed_data = Hash[data.first.to_a] transformed_data['first_name'] # => “Johnatan”

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

Не привыкайте к deprecation warnings

Для новичка любой warning поначалу кажется чем-то из ряда вон выходящим и требующим внимания. У опытных разработчиков вырабатывается чёткая установка: warning — это всего лишь warning, рутинное предупреждение. Примерно так курильщики реагируют на предупреждающие надписи на пачках сигарет.

Если мы говорим о deprecation warnings, то в большинстве случаев их можно спокойно игнорировать. Но при переходе на следующую версию того же Rails — это первое, на что стоит обратить внимание. В качестве примера приведём такое предупреждение из Rails 6.0:

Accessing hashes returned from config_for by non-symbol keys is deprecated and will be removed in Rails 6.1. Use symbols for access instead.

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

Вариантов два:

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

Выбор за вами, но всё же один из вариантов кажется более разумным. И для тех, кто решил пойти по этому сложному пути, мы можем дать интересную идею.

Любой девопс вам скажет, что нет ничего хуже заспамленных логов, в которые попадает куча устаревших версий. Их практическая ценность будет околонулевой. Грамотная обработка — ключ к успеху, благо Rails это позволяет сделать с хирургической точностью. Идея в том, чтобы настроить приложение на :notify при устаревании:

module MyAwesomeApp < Rails::Application config.active_support.deprecation = :notify end

Теперь, когда мы столкнёмся с устареванием, Rails отправит событие deprecation.rails через ActiveSupport::Notifications. Теперь нужно подписаться на эти события и настроить их обработку. Все события устаревания можно условно разделить на допустимые, которые можно смело игнорировать и недопустимые, которые нужно рассматривать, как ошибку. Цель — составление документированного списка всех устаревших версий и дальнейшее распределение их по команде.

Так, понемногу, мы будем заранее приближать приложение к запуску в следующей версии Rails без риска столкнуться с существенными сложностями. Ну а практическую реализацию такого обработчика вы найдёте в статье Stop ignoring your Rails (and Ruby) deprecations!

Интересно посмотреть

Если вы пропустили наш предыдущий Ruby meetup, ничего страшного. Мы уже выложили на наш YouTube-канал записи докладов. Рекомендуем налить себе чашечку кофе и посмотреть их в 4K качестве с отличным студийным звуком.

Александр Елистратов из BGaming сравнил RoR и GoLang с точки зрения подхода к разработке, использования библиотек и фреймворков, основываясь на личном опыте использования в коммерческих проектах:

Артем Соломатин из Samokat.tech рассказал в докладе, что такое distroless-образы, зачем они нужны. Детально разобрал их плюсы и минусы, а также привёл примеры реального использования:

Митапы

Онлайн

Ruby meetup №20

05 июля 2023

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Стучим по рельсам

Evrone digest — Mon, 03 Apr 2023 13:11:06 +0000

Наш апрельский дайджест мы посвящаем Ruby on Rails. В фокусе патч для пользовательских пространств имён и руководство по развёртыванию RoR на современной OpenBSD. В качестве «изюминки» вспомнили забавный баг GitHub десятилетней давности. Приятного чтения!

Улучшение custom namespaces в Rails 7.1

Что происходит во время автоматической загрузки веб-приложения на Rails? Вначале система сканирует и загружает все поддиректории, находящиеся в директории приложения. Исключение составляют лишь assets, views и javascript. Если мы создадим там любую поддиректорию, то Rails обеспечит её автоматическую загрузку.

При этом стоит помнить, что директории работают в роли пространств имён, а имена файлов должны соответствовать константам, которые они определяют. Если у нас есть файл app/services/users/signup.rb, то внутри него должна быть определена константа Users::Signup. Предположим, что мы хотим, чтобы все сервисы в app/services были в пространстве имён Services.

Получается, надо определить константу Services::Users::Signup. Фактически придётся создать директорию app/services/services. Помещаем туда все наши сервисы и тогда они будут в пространстве имён Services. Не самое элегантное решение. Хотелось бы иметь способ сразу прописать константу вида Services::Users::Signup в файле app/services/users/signup.rb.

С выходом патча #47583 такая возможность появится. Никакой магии, исключительно настройка автозагрузчика:

# config/initializers/autoloading.rb module Services; end Rails.autoloaders.main.push_dir("#{Rails.root}/app/services", Services)

В предыдущих версиях (до Rails 7.1) требовалось дополнительно удалять директорию app/services из ActiveSupport::Dependencies.autoload_paths. Теперь же этого делать не придётся. За дополнительной информацией советуем заглянуть в комментарии к PR Improve support for custom namespaces.

Байка про nil

Новое — это хорошо забытое старое. Предлагаем отправиться в 2013 год и вспомнить любопытный баг GitHub. Тогда каждому пользователю без аватарки присваивалась аватарка из профиля разработчика Yehuda Katz. У этого разработчика идентификатор пользователя был равен 4. Ruby же присваивал идентификатору 4 значение nil, то есть отсутствие значения. Таким образом все пользователи без аватарки приравнивались к пользователю с идентификатором 4. Баг пофиксили, но вот для многих так и осталось тайной, почему так произошло.

Разгадка кроется в правильном понимании NIL. В мире Ruby nil представляет собой объект и имеет соответствующий идентификатор (ID). Если два объекта имеют один и тот же ID, значит они оба являются одним и тем же объектом в памяти. Это очень полезно для сравнения объектов, а также позволяет сборщику мусора лучше управлять выделением памяти. Вы можете самостоятельно взглянуть на некоторые зарезервированные ID через интерактивную оболочку irb:

В Matz Ruby Interpreter (MRI) значения true/false/nil (а также значения типа Fixnum) обрабатываются особым образом и реально для всех этих объектов в памяти нет структуры с данным. ID, в этом случае, будет указателем на место в памяти, который не будет пересекаться с кучей. За подробностями советуем заглянуть в статью Дхавала Сингха (Dhaval Singh).

Rails и Falcon на OpenBSD

OpenBSD существует уже 28 лет и до сих пор сохраняет статус свободной операционной системы. Концепция OpenBSD подразумевает полное отсутствие несвободных компонентов. Никакой код не может попасть в систему случайным образом, а любая неточность в документации немедленно исправляется. Несмотря на свою «самобытность» этот дистрибутив остаётся хорошим выбором для тех, у кого надёжность и безопасность стоит на первом месте.

Пару недель назад на Reddit появилась любопытная заметка, что в сервисе GitHub Gists (сервис наподобие Pastebin) выложили подробное руководство по развёртыванию Ruby on Rails + Falcon на OpenBSD. Автор руководства утверждает, что это самое чистое ядро, пользовательское пространство и синтаксис конфигурации. Предложенный им способ позволяет запускать веб-приложения от имени непривилегированного пользователя myappy. Такой пользователь владеет исключительно директориями tmp/ и log/ и не сможет сломать основную систему в случае взлома приложения.

Мы не поленились развернуть инстанс по этому руководству и нашли несколько проблемных моментов. Чтобы не подпортить впечатление, вспомните, что UNIX-системы чувствительны к регистру. Поэтому USER стоит заменить на user.

root# adduser -group user -batch myappy

Проверить, что непривилегированному пользователю назначены верные группы можно командой:

root# id -Gn myappy myappy user

Точно также вторая команда с созданием привилегированного пользователя dev закончится ошибкой, если не поправить регистр (WHEEL заменить на wheel):

root# adduser -group wheel -batch dev

Когда мы ставим Ruby on Rails, система выдаст предупреждение, которое не стоит игнорировать, а именно создать символьные ссылки. Для версии 3.1.X эти команды выглядят так:

ln -sf /usr/local/bin/ruby31 /usr/local/bin/ruby ln -sf /usr/local/bin/bundle31 /usr/local/bin/bundle ln -sf /usr/local/bin/bundler31 /usr/local/bin/bundler ln -sf /usr/local/bin/erb31 /usr/local/bin/erb ln -sf /usr/local/bin/gem31 /usr/local/bin/gem ln -sf /usr/local/bin/irb31 /usr/local/bin/irb ln -sf /usr/local/bin/rdoc31 /usr/local/bin/racc ln -sf /usr/local/bin/rake31 /usr/local/bin/rake ln -sf /usr/local/bin/rdoc31 /usr/local/bin/rbs ln -sf /usr/local/bin/rdoc31 /usr/local/bin/rdbg ln -sf /usr/local/bin/rdoc31 /usr/local/bin/rdoc ln -sf /usr/local/bin/ri31 /usr/local/bin/ri ln -sf /usr/local/bin/typeprof31 /usr/local/bin/typeprof

Выделяем всю эту цепочку команд и вставляем в консоль. Без этого последующие команды просто не сработают. Перед тем, как выполнять множество команд, начинающихся на gem git_install, надо не забыть поставить git:

root# pkg_add git

Дальнейшие шаги по клонированию объёмного репозитория и установки гемов могут занять некоторое время, так что наберитесь терпения. Для удобства создания конфигов можно поставить привычный по Linux-системам редактор nano:

root# pkg_add nano

Подытожим: способ рабочий и результатом станет безопасный инстанс на базе OpenBSD. Возможно, кто-то однажды найдёт ваш сервер на OpenBSD с 30-летним аптаймом и приложением, которое будет работать, как ни в чём не бывало.

Интересно посмотреть

Мы рады делиться экспертизой наших специалистов. На YouTube-канале Evrone Academy появилось много новых обучающих видео по Ruby и Rails. Даже если вы давно пишете на Ruby, иногда полезно освежить знания и сверить их с другими экспертами. Ну а для новичков эти видео могут стать отличной отправной точкой.

Короткий и ёмкий формат занятий в 15-20 минут отлично подойдёт даже тем, у кого не слишком много свободного времени. Текстовые версии лекций доступны в нашем блоге на Хабре. Подписывайтесь и отправляйте эти видео своим друзьям, которые хотят начать изучать Ruby. И не забывайте нажать на «колокольчик», чтобы не пропустить новые видео.

Митапы

Онлайн

Ruby meetup №20

19 апреля 2023

Скоро мы встретимся с вами на замечательном Ruby Meetup. Программа мероприятия формируется и скоро станет доступна на странице мероприятия. Кстати, если вы не успели подать доклад, то можете это сделать прямо в режиме онлайн.

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Speeding Things Up

Evrone digest — Fri, 03 Mar 2023 12:10:19 +0000

Наш мартовский Ruby-дайджест предлагает поразмышлять над консервативным подходом к внедрению новых функций в язык. Также подумаем, как предупредить возникновение memory bloat в Rails и узнаем, как Джереми Эванс решил ускорить запуск процессов.

Консерватизм в Ruby

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

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

Ruby в 2007 году с точки зрения разработчика на С/С++, Java или PHP явно казался странным и обладал очень непривычным синтаксисом. Здесь уместно вспомнить о гипотезе лингвистической относительности, утверждающей, что структура языка влияет на мировосприятие и воззрения его носителей, а также на их когнитивные процессы. Роман «Вавилон-17», вдохновивший Юкихиро Мацумото на создание Ruby, как раз был основан на этой гипотезе. Кстати, мы брали у него интервью — советуем взглянуть, если ещё не читали.

Время шло и язык неуловимо менялся. Приоритет был сделан на стабильность и надёжность, а скорость внедрения новых функций существенно снизилась. Для некоторых разработчиков, таких как Lucian Ghinda, это стало индикатором замедления развития языка. В своей статье «We should adopt and use new Ruby features» он высказал мнение, что желание оградить язык от нововведений может негативно сказаться на его развитии.

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

Борьба с memory bloat в Rails

В одном из прошлых дайджестов мы уже упоминали раздувание памяти в Ruby. Вполне рядовая ситуация с извлечением данных из БД или Redis, чтением файлов с диска или выполнением сетевого запроса может привести к резкому выделению большого объема памяти. Если это происходит на локальной машине разработчика, то не приводит к каким-либо проблемам. Но вот в больших Rails-инсталляциях раздувание памяти может обойтись очень дорого.

Наглядно можно увидеть разницу между Transaction.sum(:amount) (где SELECT SUM(amount) FROM transactions) и Transaction.all.sum(&:amount) (где SELECT * FROM transactions с последующей отправкой по сети) на следующем примере. Для инстансов с Active Record это может выглядеть так:

ActiveRecord::ConnectionAdapters::AbstractAdapter.prepend(Module.new do def build_result(*args, **kwargs, &block) io_bytesize = kwargs[:rows].sum(0) do |row| row.sum(0) do |val| ((String === val) ? val : val.to_s).bytesize end end Aggregator.instance.increment(io_bytesize) super end end)

Подписываемся на уведомления от контроллера:

ActiveSupport::Notifications.subscribe("process_action.action_controller") do |*args| io_bytesize = Aggregator.instance.io_bytesize body_bytesize = args.last[:response].body.bytesize ratio = body_bytesize.to_f / io_bytesize Rails.logger.info "Loaded from I/O #{io_bytesize}, response bytesize #{body_bytesize}, I/O to response ratio #{ratio}" end

Завершающим штрихом создадим контроллер с нашей парой действий:

class App < Rails::Application routes.append do get '/slow', to: 'app#slow' get '/fast', to: 'app#fast' end end class AppController < ActionController::Base def slow render json: {sum: Transaction.all.sum(&:amount)} end def fast render json: {sum: Transaction.sum(:amount)} end end

Запускаем и разница будет очевидна:

Started GET "/slow" for 127.0.0.1 at 2023-02-04 23:01:27 +0300 Processing by AppController#slow as */* Transaction Load (4.5ms) SELECT "transactions".* FROM "transactions" Completed 200 OK in 43ms (Views: 0.1ms | ActiveRecord: 11.7ms | Allocations: 95836) Loaded from I/O 69899, response bytesize 15, I/O to response ratio 4659.933333333333 Started GET "/fast" for 127.0.0.1 at 2023-02-04 23:01:35 +0300 Processing by AppController#fast as */* Transaction Sum (3.1ms) SELECT SUM("transactions"."amount") FROM "transactions" Completed 200 OK in 4ms (Views: 0.1ms | ActiveRecord: 3.1ms | Allocations: 336) Loaded from I/O 7, response bytesize 15, I/O to response ratio 0.4666666666666667

Понятно, что когда проблема возникла, поправить ситуацию не слишком сложно. Можно загружать данные партиями или перенести вычисления куда-либо в другое место. Но было бы здорово не ликвидировать последствия катастрофы, а заранее предсказать её появление. Идеальный вариант — прикинуть сколько данных будет загружено из I/O и сравнить с размером потенциального ответа. Соотношение станет тем показателем, которое может выступить тревожным звоночком и которое стоит отслеживать.

Чтобы проверить такой подход на реальном приложении, не нужно писать код с нуля. Тот же io_monitor отлично упрощает жизнь. После установки его нужно сконфигурировать:

IoMonitor.configure do |config| config.publish = [:logs, :notifications, :prometheus] # defaults to :logs config.warn_threshold = 0.8 # defaults to 0 config.adapters = [:active_record, :net_http, :redis] # defaults to [:active_record] end

И включить те контроллеры, которые нужно будет проверить:

class MyController < ApplicationController include IoMonitor::Controller end

Если проблем не найдено, то в логах будет чисто. О наличии проблем будет сигнализировать строчка вида:

ActiveRecord I/O to response payload ratio is 0.1, while threshold is 0.8

Ruby-by-by

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

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

Новый загрузчик называется by. Подразумевается, что это Ruby, в котором первые две буквы уже предварительно загружены. Использована клиент-серверная архитектура, где сервер занимается предзагрузкой библиотек и слушает Unix-сокет. Клиент использует этот сокет для подключения и запуска процесса, после чего отсылает необходимые аргументы и ждёт exit code. В ответ сервер создаёт процесс, использующий текущий каталог, stdin/stdout/stderr и среду клиентского процесса. Присланные клиентом аргументы обрабатываются и финально сервер возвращает exit code 0, если всё хорошо или exit code 1 в случае ошибки.

Установить by можно одной командой:

gem install by

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

$ by-server sequel roda capybara

Теперь запускаем Ruby через by, указывая предзагруженные библиотеки:

$ by -e 'p [Sequel, Roda, Capybara]' [Sequel, Roda, Capybara]

Теперь Ruby не станет искать их и заниматься бесполезным парсингом. Выигрыш в скорости получается значительный:

$ /usr/bin/time ruby -e 'require "sequel"; require "roda"; require "capybara"' 1.67 real 0.93 user 0.66 sys $ /usr/bin/time by -e 'require "sequel"; require "roda"; require "capybara"' 0.37 real 0.20 user 0.15 sys

Те, кому этого мало, могут заняться экстримом и «вырезать» загрузку Rubygems. Детальная инструкция есть в репозитории проекта.

Митапы

Онлайн

Ruby meetup №20

19 апреля 2023

Весной мы соберёмся на замечательный Ruby Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие принимаются до 1 апреля!

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Самокритика, RubyMine и графики

Evrone digest — Wed, 01 Feb 2023 14:12:53 +0000

В этом дайджесте обсудим инструмент rubycritic, взглянем на новый интерфейс RubyMine и некоторые утилиты визуализации данных. Мы стремимся сделать ваш опыт работы с Ruby интересным!

Конструктивная критика

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

Между «показать код человеку» и «показать код программе» есть разница. Разработчики постоянно читают код и делают это чаще, чем пишут. Поэтому показать свой код коллеге и попросить оставить комментарии — отличная идея. Ну а на постоянной основе «причёсыванием» кода занимаются приложения-линтеры. Кроме них в мире Ruby-разработки существуют такие утилиты, как Reek, Flay и Flog.

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

Разработчик Guilherme Simões значительно упростил процесс самостоятельной проверки, создав проект rubycritic. В нём он объединил возможности вышеперечисленных утилит, добавив удобный интерфейс для просмотра результатов. Инструмент проверяет код и формирует подробный отчёт по всем найденным проблемам. Разработчику остаётся его просмотреть и наметить области, требующие улучшения или полной переработки. В большинстве случаев это поможет получить объективную оценку без участия человека.

Новый UI в RubyMine

JetBrains стремительно готовятся переводить RubyMine на новый UI. Нет ничего хуже неизвестности, поэтому из обновления не стали делать секрета. Новый интерфейс кардинально отличается от предыдущего. Для сравнения главное окно RubyMine со старым и новым интерфейсом:

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

Большая часть значков была перерисована для улучшения визуального баланса и удобочитаемости. Шрифт заменили на Inter, уже активно применяющийся в других продуктах JetBrains. Визуально интерфейс стал менее перегруженным. Отличный повод сконцентрироваться на коде, а не отвлекаться на лишние и редко используемые элементы.

Рисуем графики

Если нужно отрисовать график с использованием Python, то в большинстве случаев разработчики и дата-аналитики обращаются к библиотеке matplotlib. Даже далёким от программирования людям обычно не составит труда построить простой график из готовых данных буквально за 8 строчек кода. Профессионалы же получают обширный набор инструментов, который способен визуализировать любые данные. А как с этим обстоят дела в мире Ruby-разработки?

Здесь есть любопытные утилиты. Например, YouPlot. В его основе лежит библиотека unicode_plot. Это отличный вариант, если нужно одной командой загрузить файл с данными, отсортировать их и вывести в виде красивого графика или диаграммы прямо в консоль:

Rails может похвастаться инструментом Chartkick. Он позволяет буквально одной строкой на Ruby вывести нужный график. Это может быть линейный график, круговая или столбчатая диаграмма — вариантов множество. Упор сделан на то, чтобы перестать тратить время разработчиков на борьбу с библиотеками визуализации. Большинство задач решается без необходимости вдумчиво изучать документацию. Каждый график и диаграмма при этом может быть настроена десятком различных опций.

После установки gem и простой настройки окружения можно протестировать инструмент:

<%= line_chart User.group_by_day(:created_at).count %>

Обратите внимание, что для метода group_by_day надо поставить ещё один gem — groupdate.

Выводом будет красивый линейный график:

Митапы

Онлайн

Ruby meetup №18

22 февраля 2023

Совсем скоро мы соберёмся на замечательный Ruby Meetup. Программа мероприятия формируется, но регистрация уже открыта. Кстати, вы уже можете подать доклад прямо в режиме онлайн. Заявки на участие принимаются до 10 февраля!

Регистрация

Вакансии

Удаленка / Офис

Evrone

Подробнее

Подарки под ёлочкой

Evrone digest — Wed, 04 Jan 2023 12:54:48 +0000

2023 год уже здесь. Пора рассказать о самых интересных новостях Ruby-разработки. Доставайте из холодильника заботливо спрятанные салатики и закуски. Наливайте чаю или чего покрепче. Приятного чтения!

Вышел Ruby 3.2.0

Стабильность — признак мастерства. 25 декабря 2022, спустя год после релиза Ruby 3.1.0, вышла новая версия 3.2.0. Изменений много, расскажем лишь об основных. В предыдущем дайджесте мы упоминали про Opal. Идея изоморфной разработки нашла своё отражение в начале интеграции WebAssembly и системного интерфейса WASI непосредственно в язык.

Цель в том, чтобы запускать Ruby-приложения прямо из браузера или обособленных runtime, таких как wasmtime. Интерпретатор CRuby теперь умеет компилироваться в промежуточный код WASM, а для прямого взаимодействия с ОС задействуется API WASI. Стоит учитывать, что этот функционал находится в активной разработке и часть возможностей пока отсутствует. Так что там пока нет исключений, файберов и сборщика мусора.

В рамках этих же изменений была представлена wasi-vfs обвязка, необходимая, чтобы всё Ruby-приложение можно было упаковать в единый wasm-файл.

Разработчики из Shopify, объявившие осенью 2021 года о начале работы над собственным JIT-компилятором для CRuby, наконец-то могут выдохнуть. Шалость удалась, YJIT получил статус stable. Он работает на процессорах Apple Silicon, кастомных ARM-чипах AWS Graviton и даже одноплатниках Raspberry Pi 4. Написан на Rust, так что ему нужен rustc 1.58.0+. По этой причине YJIT не включен по-умолчанию.

Тем не менее, если его всё же включить, то ускорение будет значительным — до 41% по сравнению с обычным интерпретатором, если верить данным бенчмарка yjit-bench. Бонусом будет и на треть меньший расход оперативной памяти. Также в Ruby 3.2.0 появилось два механизма защиты от DoS-атак на приложение через Regexp, так называемый ReDoS. Первый улучшает алгоритм сопоставления, а второй вводит понятие тайм-аута для регулярных выражений.

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

Dockerfiles в комплекте

Древнее китайское проклятие «Чтоб ты жил в эпоху перемен» актуально, как никогда. К счастью, некоторые перемены положительные. Реагируя на современные тренды, веб-фреймворк Ruby on Rails получил интересное изменение. Оно предназначено не для разработчиков, а для DevOps-инженеров.

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

Задача автоматического создания Dockerfile для дальнейшей сборки и развёртывания обычно решалась с помощью сторонних инструментов. Но теперь RoR научился сам генерировать Dockerfile, а также вспомогательные .dockerignore и bin/docker-entrypoint. Они будут автоматически добавляться во все новые приложения и тем самым упрощать работу DevOps.

Рецепт Ruby-однострочников

Командная строка всегда была суперсилой Unix-систем. В отличие от графического интерфейса, через командную строку можно проделывать потрясающие трюки. Комбинирование внешних команд, таких как grep, sed, awk, sort и т.д. даёт возможность получать результат, не прибегая к сторонним инструментам. Это круто, но давайте задумаемся: способен ли Ruby заменить внешние команды консоли и их сочетания? Ответ однозначен — да, способен. Предположим, что есть некий текстовый файл:

$ cat table.txt brown bread mat hair 42 blue cake mug shirt -7 yellow banana window shoes 3.14

Чтобы отфильтровать только целые числа, мы можем использовать grep:

$ grep -oE '[0-9]+$' table.txt 42 7 14

А вот как это выглядит на Ruby:

$ ruby -ne 'puts $& if /\d+$/' table.txt 42 7 14

Теперь стоит задуматься над ещё одним интересным вопросом: а зачем тут вообще использовать Ruby? Тот же sed или awk мощные утилиты, способные свернуть горы. Но есть один нюанс — их синтаксис и идиомы нужно учить. Если вы Ruby-разработчик, то второй способ вам будет привычнее. Сами операции будут выполняться медленнее, зато написание станет быстрее и легче. Для многих ситуаций такой подход будет более продуктивным.

Из плюсов можно отметить, что применение Ruby даёт два крутых баффа — использование стандартной библиотеки и подключение сторонних библиотек. Даже в однострочнике это будет востребовано для выполнения каких-либо действий над файлами. Примечательно, что при этом вы не теряете возможность использовать системные команды, вызывая их методом system:

$ ruby -e 'system("echo Hello World")' Hello World

Получается, что если вы хорошо знаете Ruby, то обойдётесь без знания синтаксиса внешних команд. А если они для вас привычны и знакомы, то их комбинирование с Ruby даст превосходный буст при работе в командной строке. Детали есть в отличном обучающем материале с примерами — Ruby one-liners cookbook.

Фейки во благо

Успешная разработка приложений так или иначе требует тестовых данных. Реальные базы данных хороши, но часто требуют предварительной подготовки перед использованием. Создавать эти данные вручную долго и непродуктивно. Нужен способ эффективно генерировать их таким образом, чтобы они напоминали реальные. Но прежде чем придумывать велосипед советуем присмотреться к библиотеке faker-ruby.

Эта библиотека — порт расширения Data::Faker для Perl. В оригинале было всего лишь несколько простых генераторов, способных заполнить поля вроде Name / Phone number / Company / Address и так далее, но faker-ruby пошёл дальше. Здесь более сотни различных генераторов — от простых до экзотических, вроде генератора цитат из ситкома «Теория Большого Взрыва».

У faker-ruby есть несколько полезных опций, которые можно подкрутить, исходя из поставленной задачи. Так, например, можно заставить его генерировать только уникальные значения или же повлиять на генератор псевдослучайных чисел, чтобы получить воспроизводимые результаты генерации. Для некоторых типов данных созданы дополнительные проверки. Например, международный банковский номер счета IBAN валидируется на корректность перед генерацией, а сгенерированные VIN-коды автомобилей будут иметь правильную контрольную цифру.

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

Вакансии

Удаленка / Офис

Evrone

Подробнее

Не Rails единым

Evrone digest — Mon, 05 Dec 2022 11:12:24 +0000

Заключительный Ruby-дайджест этого года мы посвящаем обновлённому фреймворку Hanami, компилятору Opal и инструменту автоматизации ruby-nmap. Надеемся, что каждый наш читатель узнает для себя что-то новое.

Вышел в релиз Hanami 2.0

Увидела свет вторая версия fullstack-фреймворка Hanami. Мы уже упоминали о нём в одном из прошлых дайджестов. Его создавали, как полноценный легковесный аналог Rails, добиваясь меньшего потребления памяти и компактности. Немалую роль в этом играет модульность. Разработчик может взять лишь необходимые части фреймворка и не раздувать кодовую базу.

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

Полностью переписанная HTTP-маршрутизация теперь значительно превосходит по скорости Rails, Sinatra и Cuba. Также была реализована автозагрузка кода. Все ваши классы и модули будут доступны без необходимости прямого вызова через require.

Разработчики фреймворка не стали изобретать велосипед и воспользовались давно проверенным решением zeitwerk. Правда, это наложило небольшое ограничение в виде необходимости соблюдать требования Zeitwerk к файловой структуре. Ничего необычного для тех, кто знаком с Rails 7.

Наверняка вы слышали про коллекцию библиотек dry-rb. 24 гема, предназначенные решать задачи, которые не под силу стандартной библиотеке (детальнее мы рассказывали о ней в статье на Хабре). Разработка Hanami 2.0 ознаменовалась объединением усилий двух независимых команд. В октябре 2022 разработчики dry-rb закончили работу над тем, чтобы все библиотеки могли автоматически подгружаться через Zeitwerk. На наш взгляд отличная коллаборация и замечательный результат. Об остальных изменениях можно узнать из анонса на официальном сайте проекта.

Драгоценный камень Opal

Ещё одно обновление в мире Ruby-разработки. Инструмент Opal для прямой компиляции Ruby в JavaScript получил порцию изменений, призванных увеличить производительность и убрать ошибки. Новая версия 1.6 стала гораздо удобнее для разработчиков. Но для начала напомним, как это вообще работает.

Одной из попыток улучшить читаемость кода и уменьшить его размер был CoffeeScript. Тонна синтаксического сахара в стиле Ruby/Python/Haskell/Erlang действительно позволяла писать более компактно. При этом выдаваемый после трансляции код полностью проходил проверку JS Lint.

Удачным экспериментом стал и Opal, открыв новые возможности изоморфной разработки. Это же прекрасно, когда и клиент, и сервер созданы на одном языке. Забудьте про все эти страшные точки с запятой и пишите в привычном стиле. Перед тем, как пускаться «во все тяжкие» советуем попробовать Opal в действии прямо из браузера.

Если посмотреть пристальнее, то становится ясно, что Opal — серьёзная и полноценная реализация Ruby (как corelib, так и stdlib). Но вот с поддержкой нативных JS-библиотек не всё так радужно. Да, кое-какие штуки, например jQuery, заработают без дополнительных танцев с бубном. Но вот для поддержки других библиотек вероятно придётся написать собственную оболочку или же интегрировать чистый код на JS. Принцип такой же, как и у вызова внешних консольных команд из Ruby.

Авторы проекта не забрасывают своё детище и и прикладывают значительные усилия по его доработке. Новая версия стала дружелюбнее к RSpec, перестав обрезать трейсы до 15 строк, а async/await вышла из разряда экспериментальной фичи. Показательным примером стал PR, демонстрирующий, как изменение всего лишь одной строчки кода способно повлиять на производительность и компиляции, и в рантайме.

Автоматизация nmap с помощью Ruby

Даже если вы никогда не использовали nmap, то наверняка что-то о нём слышали или видели в фильмах. Этот инструмент для сканирования IP-cетей настолько полюбился киношникам, что они его пихают везде, где только можно. Об этом даже была забавная статья на Хабре. Но что если нам нужно будет использовать возможности nmap в Ruby-приложении или же мы хотим автоматизировать процесс сканирования?

В этом нам поможет пакет ruby-nmap. Он предоставляет Ruby-интерфейс для взаимодействия с nmap, а также парсер для сгенерированных nmap XML-файлов. Работает он предельно просто, вот пример из официального репозитория проекта:

require 'nmap/command' Nmap::Command.run do |nmap| nmap.connect_scan = true nmap.service_scan = true nmap.output_xml = 'scan.xml' nmap.verbose = true nmap.ports = [20, 21, 22, 23, 25, 80, 110, 443, 512, 522, 8080, 1080] nmap.targets = '192.168.1.*' end

При помощи ruby-nmap можно за короткое время создать собственное приложение или даже целый веб-сервис, обладающий всей мощью сканера. Так, например, родился небольшой проект Rmap, задействующий возможности Nmap Scripting Engine. Получившийся инструмент умеет выполнять сканирование на уязвимости, такие как SMTP-брутфорс или XSS-атака на движок WordPress. Полный перечень того, что умеет Rmap вы найдёте в статье автора проекта.

Раз речь зашла о скучном инструменте, давайте глянем нет ли в нём немного веселья. «Пасхальное яйцо» тут есть в виде вывода лога в «хакерском стиле». Делается это так, добавлением параметров -oS -

$ nmap -oS - scanme.nmap.org STart1Ng nmAp 7.92 ( https://nmap.org ) at 2022-12-05 07:27 E3T NmAp $can R3pOrt f0R $canm3.nmap.0rg (45.33.32.156) H0St iz up (0.22s latency). 0th3r aDdrE$s3z F0r $caNm3.nmap.0rg (N0T Scann3d): 2600:3c01::F03C:91ff:f318:bb2f NoT sH0Wn: 988 cl0$Ed tcP pOrtz (cONn-r3FUs3d) P0RT STAtE $eRvIC3 22/tcp 0pen $sH 25/tcp Filter3d $mtp 80/tcp 0p3n http 726/tcP f!lt3r3d uNkn0wn 1027/tcp f|ltered !Is 2005/tcp F!ltered DEsl0g1n 2605/tcp f!lTered bgPd 9929/tcp OpEn nP1NG-3cho 12174/tcp filtErEd unkn0wN 16993/tcp fIlt3red aMt-soap-https 31337/tcp 0p3N Elit3 32772/tcp f!lter3D s0m3T1Mes-rpc7 NmAp done: 1 IP aDDresz (1 h0st up) scann3d !n 20.48 $3condz

Интересно посмотреть

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

Если монады Either или Maybe для вас не простой звук, то вам явно будет интересно узнать ещё об одной абстракции — аппликативных функторах:

Опыт можно получать разными способами. Если внимательно посмотреть на процесс разработки популярных библиотек, то можно почерпнуть немало полезной информации:

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

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

Вакансии

Удаленка / Офис

Evrone

Подробнее